Linux kernel compatability

Matthew Jacob mj at feral.com
Tue Jan 4 01:54:44 UTC 2011


>> 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 
> it.
>
>

You should read 
http://www.kernel.org/doc/Documentation/stable_api_nonsense.txt 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 
with this).

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 
distros).

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 
approach here.

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.



More information about the freebsd-arch mailing list