|| ||Chris BeHanna <chris-AT-behanna.org> |
|| ||arch-AT-freebsd.org |
|| ||Re: Linux kernel compatability |
|| ||Tue, 4 Jan 2011 13:15:53 -0600|
|| ||Article, Thread
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?
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
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.
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"
to post comments)