|| ||Matthew Jacob <mj-AT-feral.com> |
|| ||freebsd-arch-AT-freebsd.org |
|| ||Re: Linux kernel compatability |
|| ||Mon, 03 Jan 2011 17:21:33 -0800|
|| ||Article, Thread
>> Also, linux likes to change things very rapidly. Not to mention a
>> lot of their APIs go against the grain on BSD and we would not find
>> them aesthetically or architecturally pleasing.
> Yea, that's happened so often, one has to wonder if it is intentional
> on their part :) But, alas, I think phk's signature actually explains
You should read
http://www.kernel.org/doc/Documentation/stable_api_nonsen... for a
reasoning. It's also a misreading of both motive and capabilities to
ascribe either malice or incompetence to the linux folks.
On the title subject, having written several multiplatform drivers and
been involved trying to write APIs and ABIs common to multiple platforms
and OS' for the last 20 odd years or so, I have to say I have very mixed
feelings about the approach Jeff has taken here.
Syntactic differences between different OS functions are *generally*
trivial. printf is printf.
Semantic, and implied semantic differences can be tricky. The linux
locking model is fundamentally different from the FreeBSD, and only
conscious and careful programming in code that calls shim layer stuff
can avoid problems (although maybe Jeff has been cleverer than I can be
Given the above, centralized KAPI services that multiple OS platforms
can share seem a hard goal to reach. There was at least one (sponsored
by SCO) which was a complete non-starter (despite the best of
intentions). There have been several hardware based efforts that have
also come a cropper (I20 and OBIOS).
Even *within* a single OS community, variants abound that are
irreconcilable (the multiple *BSDs; AT&T vs BSD; .....). And once you
get outside the kernel, it's complete chaos (the multitude of Linux
I take from all of this that only select and relatively contained kernel
subsystems are good candidates for multiple platform instantiations.
Direct hardware drivers are generally pretty good for this since they
can usually be written with shim type supports pretty easily.
Filesystems are tricky. The attempts by SGI to maintain multiple
platform versions of XFS have failed spectacularly. The GFS folks gave
up on this one early.
OFED is something of a special case. It's a very large body of code,
written specifically for Linux, and is essentially the de facto standard
for HPC interconnects. Like I said, I have mixed feelings about Jeff's
On the one hand, that's a huge shim layer to write (10K LOC!).
On the *other* hand, it makes importation of updated (Linux based) code
quite workable. What that *does* imply is that native OFED development
will unlikely ever be undertaken on FreeBSD (probably fine- whoza gonna
pay for it that ain't paying for Linux development already?).
The other thing to ask in making for common functionality is whether or
not there are performance and/or functionality tradeoffs being made.
There are things you can do in the FreeBSD kernel that you can't
(easily) do in Linux (and vice versa). That's another consideration.
Anyway, to end this meandering email, my suggestion would be "Yes, the
10K LOC would be useful for all modules to use!", but only expect it to
work (well) for OFED.
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"
to post comments)