Date: Tue, 4 Jan 2011 13:15:53 -0600 From: Chris BeHanna <chris@behanna.org> To: arch@freebsd.org Subject: Re: Linux kernel compatability Message-ID: <55CB0273-36D6-44FC-9F28-8E59003051D2@behanna.org> In-Reply-To: <alpine.BSF.2.00.1101041744580.28912@fledge.watson.org> References: <82826.1294088199@critter.freebsd.dk> <alpine.BSF.2.00.1101031343210.1450@desktop> <alpine.BSF.2.00.1101041744580.28912@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jan 4, 2011, at 12:18 , Robert Watson wrote: > On Mon, 3 Jan 2011, Jeff Roberson wrote: >=20 >>> Those where there are substantial differences, we should only have = one compat layer, not one for each driver. >>=20 >> 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. >>=20 >> 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. >=20 > 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. >=20 > 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? >=20 > [...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. --=20 Chris BeHanna chris@behanna.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55CB0273-36D6-44FC-9F28-8E59003051D2>