Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Chris BeHanna <chris <at> behanna.org>
Subject: Re: Linux kernel compatability
Newsgroups: gmane.os.freebsd.architechture
Date: Tuesday 4th January 2011 19:15:53 UTC (over 6 years ago)
On Jan 4, 2011, at 12:18 , Robert Watson wrote:
> On Mon, 3 Jan 2011, Jeff Roberson wrote:
> 
>>> Those where there are substantial differences, we should only have one
compat layer, not one for each driver.
>> 
>> I would like this to be the case.  So we can converge on something
complete. There are of course big differences between minor linux kernel
revisions and that poses problems.  However those should be easier than the
bsd/linux differences.
>> 
>> I think my proposal is to move these files to a more generic location so
they are more visible and available to other projects.  Maintainers of
individual kernel ports would have to decide if they want to use what is
there.
> 
> I think it's worth making a comparison with how we handle our Open
Solaris shim parts, found (largely) in opensolaris.ko, which supports
Solaris-derived features such as DTrace and ZFS.  It is forced to address
header location issues, license isolation issues, etc, and there may be
some useful lessons there.
> 
> There are also some potentially relevant problems: for example, in a
formal sense, what version of an OS's KPI do we track?  I'm no expert on
opensolaris.ko, but my recollection is that we had a problem for a while
where our versions of DTrace and ZFS did not come from the same version of
Solaris. This even though the Sun (now Oracle) folks put a lot of work into
stable kernel programming interfaces for dervice driver authors, etc.  The
Linux community is less well-known for its efforts in this area, and have
faster-moving KPIs.  Do we think there's sufficient KPI stability there to
have a linux_kpi.ko (or whatever) that can serve more than one major
consumer? Or is it sufficient to say that all Linux-derived code should
track one Linux kernel version?
> 
> [...snip...]

	Please forgive me for intruding, but I have some experience with this that
you may find valuable.  In a past life, I worked at a storage company,
where my main area of responsibility for some years was porting our
out-of-tree file system kernel module across several Linux distros on
several architectures, a feat which would not have been possible without a
very large kAPI abstraction layer and a clever mechanism for cross-building
different kernel versions on the same machine, in the same build output
tree.

	I would say that you want to pick a major release of one or at most two
major commercial distros (I'll pick on Red Hat Enterprise Linux and the
enterprise SuSE for illustration), and track the major releases of them
that correspond to roughly the same Linux kernel version, and then STICK to
that for the life of a given FreeBSD release stream.  Commercial vendors
backport fixes into their otherwise-fairly-stable major releases, which
minimizes your pain. There are still some changes here and there along the
way, and you have to decide how many kernel config options you are willing
to support (I'd suggest the default SMP, maybe the default PAE, and punt
everything else or you'll go mad).

	The combinatorial pain of committing to more than that leads to a desire
for seppuku:  I had to support multiple kernel versions each (and often
multiple configurations per kernel) for Red Hat 7, 8, 9; RHEL 4 and 5, SuSE
Enterprise 9, 10, 10.1, and 10.2, SuSE Desktop 9 and 10, and Fedora 4, 5,
and 6 across x86, x86-64, and IA-64, and it ended up being more than 400
binaries to be generated, tested, and delivered every time we issued a
patch release.

	Linux is shifting sand.  Picking and sticking to the default
configurations of at most one major release each of two major distros, per
FreeBSD release stream, at least puts you on the hard-packed stuff near the
tide line.  Even that is a moving target, as RHEL and SuSE will issue a
frequent stream of security updates that will bump kernel patch versions,
so "version magic" gets to be a pain to get modules to auto-load, though
there is some provision for "weak" symbol versioning in 2.6.18 and beyond.

-- 
Chris BeHanna
[email protected]

_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[email protected]"
 
CD: 3ms