|| ||Jeff Roberson <jroberson-AT-jroberson.net> |
|| ||arch-AT-freebsd.org |
|| ||Linux kernel compatability |
|| ||Mon, 3 Jan 2011 10:31:24 -1000 (HST)|
|| ||Article, Thread
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,
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
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?
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"
to post comments)