Truly Free drivers could use a stable API too [LWN.net]

Truly Free drivers could use a stable API too

Posted Nov 10, 2005 5:00 UTC (Thu) by elanthis (guest, #6227)
Parent article: On binary drivers and stable interfaces

Let's take a really simple situation:

1) User has Distro 4.0 installed on their machine, which has kernel 2.6.14.
2) Distro 4.0 will never provide an update to any other kernel version, because kernels need to be tested and patched and stabilized and all that effort is going into Distro 4.1 to be released in six months.
3) New hardware comes out, and it has a driver which has been included into the kernel... versions 2.6.16 and onward, anyways.
4) User buys said new hardware but has no way to get it to work without manually downloading, possibly patching, and installing the kernel, and also thereby giving up automatic security updates from the vendor.
5) User is screwed.

A stable ABI isn't really necessary, I'll note. A stable API is. With a stable API, at the very least, a tool like DKMS can do its magic and users can pop in that new GPLd driver for that new hardware, wait a couple seconds while a nice GUI install tool shows a little progress bar while GCC compiles the driver, and then have working hardware.

There are cases for stable ABIs even with purely GPLd drivers, mostly for installer needing to write to disks that lack drivers for the controller in the install image, but I suppose installers could start offering minimalistic in-memory compiler toolchains to work around that.

Today's Linux userbase can probably deal with shopping around for hardware that's several months/years old to ensure their bleeding-edge development distribution will support it, but the mainstream market just won't accept that. I'm not personally sold on the idea that we have to get the mainstream market to accept it, but there are vendors who do think so (Canonical, Linspire, etc.), so for their sake I hope the kernel developers can find some kind of solution.

I guess another way of putting it is that the kernel needs better support for out-of-tree (even 100% GPL) drivers, because in-tree drivers aren't always available to users running older systems.

(Log in to post comments)

Truly Free drivers could use a stable API too

Posted Nov 10, 2005 9:06 UTC (Thu) by khim (subscriber, #9252) [Link]

You can shorten your tirade to this:

1) New hardware comes out, and it has a driver which has been included into the kernel... versions 2.6.16 and onward, anyways.
2) User is screwed.

Why ? Easy: it's common practice to only support "certified hardware" - and I fail to see why it's so much easier for vendor to certify some alien driver then it is to certify 2.6.16 (or to backport driver to vendor-patched 2.4.14).

This is not a hoax, you know, this is from server on our work:
$ uname -a
Linux mccme.ru 2.6.14 #1 PREEMPT Sat Nov 5 00:00:31 MSK 2005 i686 unknown
$ cat /etc/redhat-release
Red Hat Linux release 6.2 (Zoot)

I fail to see the need to separate drivers and kernel. Supported drivers - are included in kernel, the way to get new drivers is to install new version of kernel. All other drivers are unsupported and experimental - use on your own risk, but YMMV. 3 years is clearly not enough (system discussed above was installed back in 1997 and while moved two times from one hardware set to another is still in active use). Interfaces between kernel and userspace are stable enough, in-kernel interfaces are in constant flux. This is how it always was, why should we change this ?

Truly Free drivers could use a stable API too

Posted Nov 10, 2005 10:09 UTC (Thu) by simlo (subscriber, #10866) [Link]

To install a new kernel you have to reboot - very Windoze like :-(

I totally agree with the long comment above: What is needed is a "micro-kernel" approach. Drivers should be able to run in user-space. The stable driver API should be in user-space. Hardware vendors can use that to write their close source drivers. That way experiments like Ingo's realtime-patch would still work since no closed source module have access to any kernel internals - only a few system calls. If hardware vendors complain over performance: Release the driver under GPL and move it into the kernel.
If a company do not want to do that, someone could trace what is going on between the driver and the kernel and thus more easily write a free driver.

I have dropped the smb/cifs drivers in the kernel and use smbnetfs which is build on top of fuse. Now a bug in the smb implementation can't crash my machine. I can even use Kerberos as authentification. Moving stuff into userspace _works_ - at least sometimes. Please, don't go into religious war between microkernel vs. monolitic kernels. As I see it Linux should be a _mixture_ using both techniques where they fit best weighing performance, stability, ease of development, flexibility and licensing issues.

Truly Free drivers could use a stable API too

Posted Nov 10, 2005 15:19 UTC (Thu) by kfiles (subscriber, #11628) [Link]

> To install a new kernel you have to reboot - very Windoze like :-(

Well, to install a new card you have to reboot too, so it doesn't seem so strange to reboot to a new kernel at the same time. :)

Now for USB stuff and network protocols, DKMS hotpluggable drivers certainly seem more appropriate. I have installed 3 different versions of the PPTP module via DKMS without rebooting.

Thanks,
--kirby

kexec()

Posted Nov 10, 2005 18:26 UTC (Thu) by AnswerGuy (guest, #1256) [Link]

Depending on your precise definition of "reboot" it's also possible with newer kernels to run the kexec wrapper around the kexec() system call
and thus load a new kernel without a firmware reboot. (Also available
with the old 2-kernel monte patches and utility).

Of course all user processes are killed through a kexec() ... and all
devices are re-initialized by the new kernel. Thus this is a "reboot"
in that sense of the term.

Combine that with some Mosix and Xen like process checkpointing and suspension and you could very well devise a Linux system that would not
have to be "rebooted" in order to switch in a new kernel.

But it's quibbling to compare the necessity of rebooting into a new kernel
with the infamous reboots required for trivial system settings in earlier versions of MS Windows. I used to have a poster with a genuine appearing MS Windows GUI dialog that read:

You have moved your mouse.
A system reboot is required for this change to take effect.
[Ok]

JimD

Truly Free drivers could use a stable API too

Posted Nov 10, 2005 22:52 UTC (Thu) by Duncan (guest, #6647) [Link]

>> To install a new kernel you have
>> to reboot - very Windoze like :-(
>
> Well, to install a new card you
> have to reboot too[.]
>
> Now for USB stuff and network protocols[...]

Actually, for hotpluggable stuff like USB, there are kernel modules.
Kernel modules can be compiled separately, against the codebase used to
compile the running kernel, and can then be modprobed, without rebooting.

As for closer to the core hotpluggability, memory and CPUs and the like,
the kernel isn't quite there yet, but support is actively being worked up
and is already there to some degree. For this sort of support, modules
aren't generally needed, because support for a base level will be compiled
in and additional CPUs or memory use the existing support.

Of course, one still has to reboot (or kexec) to a new kernel if switching
to hardware of a different architecture. However, I don't know if
anything supports that, and the call for such support isn't that great,
anyway, tho it could be useful in certain high availability situations.

BTW, the user mode drivers comments someone made are a good idea, as well.
There's nothing stopping that (tho more integrated/direct kernel support
in some cases would be very useful, think fuse implementation before and
after the kernel support for it), and indeed, the kernel's GPL preamble
specifically states that the restrictions of the GPL do NOT apply to
userspace, so binary drivers are with no controversy completely legal
there (altho there remains disagreement of whether they are /moral/, but
it's the usual controversy of whether /any/ binary-only code is /moral/).
The problem of course is the performance bite. It's fine in some cases,
particularly where there's direct kernel support for the userspace drivers
as with fuse, but would suck for something like NVidia's video drivers.
Very good point made, none-the-less.

Duncan

Truly Free drivers could use a stable API too

Posted Nov 11, 2005 1:48 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

Actually, for hotpluggable stuff like USB, there are kernel modules. Kernel modules can be compiled separately, against the codebase used to compile the running kernel, and can then be modprobed, without rebooting.

In this thread, we're talking about unstable APIs. You probably cannot just separately compile the loadable kernel module against the currently running kernel because the base kernel / device driver LKM interface has changed.

The original poster makes the point that with a stable API, your method would work. But without one, you need to upgrade your entire kernel in order to use a new loadable kernel module. And a reboot is just one of the pains of doing that.

User space drivers solves the problem only if we assume that the user space interface is stable like user space interfaces we know today.