Date: Mon, 3 Jan 2011 13:02:23 -0800 From: Alfred Perlstein <alfred@freebsd.org> To: Jeff Roberson <jroberson@jroberson.net> Cc: arch@freebsd.org Subject: Re: Linux kernel compatability Message-ID: <20110103210223.GV2973@elvis.mu.org> In-Reply-To: <alpine.BSF.2.00.1101031017110.1450@desktop> References: <alpine.BSF.2.00.1101031017110.1450@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
* Jeff Roberson <jroberson@jroberson.net> [110103 12:51] wrote: > Hello Folks, > > Some of you may have seen my infiniband work proceed in svn. It is coming > to a close soon and I will be integrating it into current. I have a few > patches to the kernel to send for review but I wanted to bring up the KPI > wrapper itself for discussion. > > The infiniband port has been done by creating a 10,000 line KPI > compatability layer. With this layer the vast majority of the driver code > runs unmodified. The exceptions are anything that interfaces with skbs > and most of the code that deals with network interfaces. > > Some examples of things supported by the wrapper: > > atomics, types, bitops, byte order conversion, character devices, pci > devices, dma, non-device files, idr tables, interrupts, ioremap, hashes, > kobjects, radix trees, lists, modules, notifier blocks, rbtrees, rwlock, > rwsem, semaphore, schedule, spinlocks, kalloc, wait queues, workqueues, > timers, etc. > > Obviously a complete wrapper is impossible and I only implemented the > features that I needed. The build is accomplished by pointing the linux > compatible code at sys/ofed/include/ which has a simulated linux kernel > include tree. There are some config(8) changes to help this along as > well. > > I have seen that some attempt at similar wrappers has been made elsewhere. > I wonder if instead of making each one tailored to individual components, > which mostly seem to be filesystems so far, should we put this in a > central place under compat somewhere? Is this project doomed to be tied > to a single consumer by the specific nature of it? > > Other comments or concerns? I think this is really cool. Brilliant actually. What do you think about proposing it on some standards list as a cross unix KPI? That way we can see upcoming changes and maybe have a say in pushing back on gratuitous changes that would break our clients? -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110103210223.GV2973>