Driver core functions: GPL only

[Posted September 29, 2004 by corbet]

Patrick Mochel may have been expecting to start a flame war with this patch, which changes most of the driver core functions to be exported only to GPL-licensed modules. The affected functions include the bus-level code, classes (but not class_simple), device_register() and friends, the platform and system bus functions, low-level sysfs functions, and the kobject primitives. In fact, the flame war failed to materialize; nobody seems to be upset by these changes. Whether Patrick is pleased or disappointed by the silence is for him to say.

The affected functions are a fundamental component of the Linux driver model; they are used by every device driver and filesystem, and by many other parts of the kernel as well. Even so, few, if any, proprietary modules will be affected by this change. The interfaces used by most modules are built on top of - and hide - the driver core. Thus, it is a rare driver which calls device_register(); instead, something like usb_register_dev() is used. Those upper-layer functions remain exported to all modules.

So why make the change? Patrick's reasoning is that he wants all users of the low-level functions to be part of the mainline kernel tree.

In short, being able to audit all of the users of these functions is necessary to their continued evolution (whatever that may entail). It would make the most sense if all users were part of the kernel, and it makes little sense to support their use by any unknown or binary modules.

As the kernel tree becomes more dynamic internally, it will be increasingly hard for external modules - free or not - to keep up with the changes. It would not be surprising to see ever more "encouragement" to merge external modules into the mainline. Code which remains outside will require a higher level of maintenance, or it is likely to break frequently.

Index entries for this article
Kernel	Device model
Kernel	Modules/Licensing
Kernel	Sysfs

to post comments

Mistake

Posted Sep 30, 2004 3:01 UTC (Thu) by elanthis (guest, #6227) [Link] (15 responses)

And usability basically disappears with these kinds of changes.

Sure, all the drivers a user will ever need is in the latest kernel. Too bad the vast majority of users have no way to *get* that latest kernel. They're stuck with whatever is packaged for them and distributed on their OS. Which, for real users, will generally *not* be the latest 6-month cut of Fedora or Debian unstable.

The result? It's impossible for the users, ever, to get new hardware to work on their machine, or install the OS on new hardware. Both the hardware and the in-tree drivers will have to have existed for a couple of years before you can reliably expect most users to be able to use the hardware.

I don't really care if you say all drivers must be GPLd. Go for it. Just make it possible for users to install those GPL drivers on their systems without needing to be a Linux guru.

It's not that users are stupid and can't learn; it's that they shouldn't have to, and many flat out don't want to. That's that.

Without, at the bare minimum, API stability (which does *not* force stagnation, if you manage the API versioning intelligently!), Linux just isn't going to be usable for most real-life users that don't have a Linux kernel hacker around to manage everything for them.

Mistake

Posted Sep 30, 2004 3:38 UTC (Thu) by dvdeug (subscriber, #10998) [Link] (3 responses)

If they can't get a new kernel, where are they going to get modules compiled for thier current kernel? Why isn't making the most current kernel available for older distributions better a good solution to this problem?

Mistake

Posted Sep 30, 2004 14:12 UTC (Thu) by elanthis (guest, #6227) [Link] (2 responses)

Because each minor kernel revision includes massive changes. It's foolish to expect a distro to QA a new kernel when it has such huge differences in it besides just updated drivers. You'd either spend sickening amounts of developer time for each kernel release, or you'd destabilize your users's systems.

Getting new drivers is easy. The driver could be delivered on a CD with the hardware. Web sites (like the hardware vendors' or a central Linux Driver Database) could contain simple driver packages.

As things work now, to release a usable driver, you have to package the driver for each kernel revision of each os release of each architecture of each os. That's a hell of a lot of drivers.

You don't really *need* ABI stability. Even just API stability would work. Then you could use something like DKMS, or another similar system, to install drivers. A simple "driver package" could be delivered on CDs or on a vendor's web site that let normal users click-and-install drivers; the driver would just be compiled and installed, initrd images updated, etc. When a new kernel is installed, the driver would just be rebuilt. That's only possible with a stable API, though.

A stable ABI would help when you want to install an OS on newer hardware. A compiler is generally not going to be available on the installation image, and even running a compiler in that environment is iffy at best. A stable ABI would let vendors ship a single binary that users could load off of a disk during installation to get support for such things as disk controllers or network cards that they need access to in order to install the machine.

Again, this is all assuming only GPL modules. I'm fine with the kernel devs legally banning non-GPL modules. Just make it possible to actually *use* the GPL modules.

stability is a chimera

Posted Oct 5, 2004 8:35 UTC (Tue) by mbp (subscriber, #2737) [Link] (1 responses)

Person A would like the kernel to stop changing altogether, except for remotely-exploitable security fixes. Person B wants it to stop changing except for serious bugs and all security fixes. Person C wants all the above, plus support for yet another little USB dongle. Person D needs support for a major new class of device such as SATA, a clean implementation of which means reorganizing the block layer. Person E needs the kernel to run well on their new 64-way Itanium and so needs variable size pages and other trickery.

Who should win? Just how stable do you want the kernel to be? There is no way to please everyone? Any feature which you consider churn is absolutely critical for someone else.

It is a fundamental design assumption of Linux that the internals can change to meet changing circumstances. If new devices require changing the abstractions, they will change. Trying to keep an ABI stable favors ABC at the expense of D and E, and there's no reason to do so.

In the 2.6 model, the kernel.org tree is not going to try to please any of these people. They are going to develop the kernel as best they can.

If you need more stability than that, you need to do it yourself or get it from a distribution. Linus is doing nothing to prevent people making branches with whatever stability criteria they want. He's just not going to interrupt development to pursue the criteria that you personally want, because other people have different goals.

This is a key difference between Linux and commercial projects: they have a single timeline, a single project plan, a single set of stability goals, and can decide to go into a stablity phase. That doesn't make sense for a project with such diverse users as the kernel.

stability is a chimera

Posted Oct 13, 2004 15:30 UTC (Wed) by jai0 (guest, #23440) [Link]

Dude, that was just amazing. Now I've got a good reply to those who ask me about these zillion kernel versions, incompatible kernel modules, etc.. Thanks.

Mistake

Posted Sep 30, 2004 4:46 UTC (Thu) by mdomsch (subscriber, #5920) [Link] (2 responses)

DKMS - Dynamic Kernel Module Support, exists to solve exactly this problem. The goal is that one can take driver code from the latest kernel, and, through the magic of DKMS and its use of the KBuild system, compile those drivers for earlier kernels.

http://linux.dell.com/dkms/

Mistake

Posted Sep 30, 2004 14:13 UTC (Thu) by elanthis (guest, #6227) [Link] (1 responses)

DKMS is useless if the API breaks. You can't recompile the driver if the API it requires changes or disappears when you update the kernel.

Mistake

Posted Sep 30, 2004 18:26 UTC (Thu) by hamjudo (guest, #363) [Link]

You can't recompile the driver if the API it requires changes or disappears when you update the kernel.

Unless you or your driver compiler tool know how to fix up the API. Look a couple stories up at remap_pfn_range(). If you follow the link to the actual patch, you'll see a temporary wrapper for maintaining the old API until the complete patch set is applied.

That class of API change lends itself to some simple heuristics. In this particular case, if the compiler complains that remap_page_range() is missing, add that 8 line inline function and recompile.

Many API changes really are that simple. Most of the more complex API transformations would still be straightforward to code in Perl, Python or the source code manipulation language of your choice. This is assuming that your goal is working code, rather than high performance code.

It is not hard work, but it is a lot of work, and people with the right skills would have to be convinced it is worth doing.

I don't believe it is worth doing at this time.

Mistake

Posted Sep 30, 2004 7:24 UTC (Thu) by khim (subscriber, #9252) [Link] (3 responses)

Ok. Currently distribution makers avoid automatic kernel upgrades (if you'll not count Gentoo and such). And this should be so since_______________(insert your reasoning here).

I've not seen any. For the most part kernel is repository of hardware drivers. Upgrade of it looks like a perfect way to get support for the new hardware. And no, distributors choice to not provide latest kernels for old distributions has nothing to do with kernel. You can use kernel 2.4.27 in place of 2.4.0 easily (no userspace changes are required unless you want to use new, added functionality - it's your choice, not obligation) and you can not expect to keep drivers API unchanged between 2.4.x and 2.6.x so what's the problem ?

And if you think "stable ABI" will solve this last problem (drivers from 2.6.x in 2.4.x, drivers from 2.8.x in 2.6.x, etc) then look here. Currently Save-Solaris-x86.ORG is running Solaris 7 x86 while AMI (now LSI Logic) corrects problems with their driver under Solaris 8 - and this is despite huge (real huge, no sarcasm here) efforts from Sun side to keep usage of drivers across the broad range of Solaris releases possible. No, it just does not work. You still end with needing some explicit changes if you want to support few major revisions of system - and then why not to port driver to new API ?

You can't always cleanly replace a distros kernel..

Posted Sep 30, 2004 8:18 UTC (Thu) by csamuel (✭ supporter ✭, #2624) [Link] (2 responses)

> And no, distributors choice to not provide latest kernels for old
> distributions has nothing to do with kernel. You can use kernel
> 2.4.27 in place of 2.4.0 easily (no userspace changes are required
> unless you want to use new, added functionality - it's your choice,
> not obligation)

Thus speaks someone who hasn't used Redhat Enterprise Linux 3, where RH
backported NPTL from 2.6 and enabled it in glibc with the result that if
you install a stock 2.4 kernel instead of a RHEL3 kernel RPM various
userland programs (such as up2date for instance) break. :-(

If you install a stock 2.6 kernel it all magically works again..

Sigh..

You can't always cleanlyreplace a distros kernel.. distro support problem

Posted Sep 30, 2004 8:51 UTC (Thu) by Duncan (guest, #6647) [Link]

That's a vendor issue, not a kernel hacker problem. People pay RH big
money for RHEL and RHEL "enterprise quality" support, and they should be
talking to RH if they don't get it. It's RH's choice to do such
backporting (not that I disagree with their reasons, but it remains their
choice in any case), and their problem to support their choice.

As for users, well, it was the user choice to spend all that money and go
with RHEL. If they aren't happy with the results, maybe they better
change vendors.

Duncan

You can't always cleanly replace a distros kernel..

Posted Sep 30, 2004 9:43 UTC (Thu) by tzafrir (subscriber, #11501) [Link]

RHEL's support contract explicitly forbids you to use a different kernel you compiled on your own unless RH's support authorized you to do so. Not happy with that? contact RH's fine support people and complain that a certain hardware is not supported with their kernel.

An alternative route: take the kernek from the latest rawhide. It generally contains all of RH's backports.

Ditto for Mandrake/cooker , and almost any other distro.

SuSE is a sore ommition here. No way to get the latest from SuSE/"unstable" .

Mistake

Posted Sep 30, 2004 8:39 UTC (Thu) by dvrabel (subscriber, #9500) [Link] (3 responses)

Isn't this argument several years old (and out-of-date) now?

Mistake

Posted Sep 30, 2004 12:48 UTC (Thu) by Frej (guest, #4165) [Link] (2 responses)

No, you can not expect upgrading a kernel will work.
Upgrading kernel for newer hardware support, might break other interfaces.

Especially with the new even more horrible release process (From a user's perspective, non existing).

Mistake?

Posted Sep 30, 2004 18:34 UTC (Thu) by bronson (guest, #4806) [Link]

Idealistically, I agree with you: upgrading a kernel these days is scary. It's easy to blame the new release scheme.

Practically, though, it's always been like this. In the 2.2 series, I had deep fear of upgrading a kernel up until around 2.2.8, and in 2.4 all the way up to 2.4.16 or 2.4.18 somewhere. Just think of it as part of Linux's charm.

Mistake

Posted Oct 5, 2004 8:36 UTC (Tue) by mbp (subscriber, #2737) [Link]

So use a kernel that's qualified and tested to work with your hardware.

If you install a random kernel on random hardware you have to be prepared for it to break.