LWN: Comments on "KS2008: When should drivers be merged?"

KS2008: When should drivers be merged?

giraffedata — Fri, 19 Sep 2008 23:43:34 +0000

Much of the crappiness being referred to here is not general crappiness that you might get from an incompetent or rushed engineer -- its just failure to conform to standards of the Linux kernel. It could be a different coding style. It could be stuff that was designed to meet requirements unrelated to the requirements of mainline kernels (e.g. the code was ported from Windows). It could be code that doesn't work in some of the myriad scenarios it might find itself in, in which it was never needed to work before.

KS2008: When should drivers be merged?

njs — Fri, 19 Sep 2008 01:27:36 +0000

IIRC it's common for (clueful) vendors to provide docs under NDA with the actual release embargoed until the hardware is announced. Or there are weird tricks, like drivers landing in the mainline kernel under code names, and then when the press release goes out so does the rename-all-the-symbols-in-that-driver patch.

KS2008: When should drivers be merged?

iabervon — Wed, 17 Sep 2008 22:16:48 +0000

Releasing vendor drivers wouldn't really help much, since it's pretty late by the time users get anything released by the kernel team. Getting drivers for pre-release hardware to kernel reviewers under NDA could be a big help, though, particularly if that included distro representatives who could get a package for the module through QA and ready to release simultaneously with the hardware. I wonder if big hardware vendors would be interested in the linux driver project that Greg KH runs, for the express purpose of collecting acks from reviewers (and, of course, comments, but those would presumably be uninteresting before they could be posted) in advance of the code going out to the world.

KS2008: When should drivers be merged?

mjthayer — Wed, 17 Sep 2008 19:53:10 +0000

Perhaps this would be a case to ship the vendor's drivers "until something better is available", probably disabled by default in the main kernel tree. Or alternatively, to have a private mailing list with relevant kernel drivers that they can submit to, so that their code will not be made public before they are ready.

KS2008: When should drivers be merged?

iabervon — Wed, 17 Sep 2008 17:10:17 +0000

There's the sort of fundamental problem that vendors don't want to announce unreleased hardware, let alone publish drivers for it, and then they obsolete the hardware sooner than the latency in keeping a kernel release into users' hands. They're doing their release cycle based on the idea that they'll ship drivers, which they write internally and which don't have to be maintainable (i.e., only have to work with one or two already-released OS versions), with their hardware.

The solution is probably for them to design hardware that functions okay with drivers that aren't specifically for that hardware release, such that Linux users get hardware that works fine today and performs better over time (as newer drivers notice more hardware features and use them).

What about when the author is disinclined to merge?

chrispe — Wed, 17 Sep 2008 08:15:23 +0000

I rely on 2 long-standing unmerged drivers on a daily basis...

yaffs2 (http://www.yaffs.net/) is an excellent NAND flash filesystem with all necessary features and acceptable mount times for large devices. It is widely used in embedded systems shipping today. A barrier to merging may be the existence of a compatibility layer allowing the filesystem to compile on other platforms and bare metal (eg: RTOS's & bootloaders).

drbd (http://www.drbd.org/) is a distributed block device driver used in high-availability systems and an integral part of the Linux-HA architecture. A barrier to merging may be existing features in the main line with partially overlapping goals.

I've asked on the mailing lists of both these projects when they will be merged quite some time ago and got vague promises, but no visible effort towards inclusion. They are both backed by small companies which may be unwilling to give up control. They may simply have other priorities.

I'd like to see a way for these sorts of projects to get merged. Perhaps some body could be persuaded to provide the authors with a financial incentive to get the merge work done.

Both of the examples above are large bodies of work which I'm very glad exist in any state of merging. Given the effort and generosity of their authors over a long period, I wouldn't like to see the projects forked for inclusion.

KS2008: When should drivers be merged?

tialaramex — Tue, 16 Sep 2008 19:31:21 +0000

Most in-house stuff is crap. Never designed to be looked at by the general public, still less criticised by dozens of expert kernel developers. It is very noticeable, for example, that an in-house program which I got cleared to be released as GPL, is still sat there waiting for me to take action because I realised after getting the OK to release it that it needs at least a couple of days of extra work doing to it before outsiders will be able to use it sensibly. It mistakenly relies on an extension to a standard that it implements, and (a colleague pointed out when I enquired) nobody except us implements that extension. Whoops. From any outsider's point of that program is currently crap, so I won't be releasing it until it's not crap.

Developing the drivers for yet another brand of 100Mbit network card is not most people's dream job, so it should be no surprise that the developers working for a lot of hardware outfits are not the best in the business. That doesn't mean that /they/ are crap, but it does mean that their code isn't necessarily going to be up to the standard people expect from Linux.

Old in-house drivers weren't any better, I've seen the code that made the Video Toaster go. It's awful, you'd never have guessed that the Video Toaster was a roaring success if you tried to judge based on the quality of source code.

But actually today's drivers have even more opportunities to be terrible than did those from the Video Toaster era. You can screw up suspend and resume, you can fail when there are multiple CPU cores, there are countless novel ways to screw up. Microsoft has a QA process for new drivers, which must be passed before they'll certify the drivers for use with ordinary Windows PCs. Perhaps their QA process doesn't use the word "crap" but the judgement is the same, "this driver isn't good enough, try harder next time".

New drivers

corbet — Tue, 16 Sep 2008 15:26:07 +0000

I don't think I wrote anything to give that impression. There is no such general feeling. It is true, though, that some new drivers are poorly written. That's what the discussion was about; nobody worries about the well-written drivers, dozens of which go into every kernel release.

KS2008: When should drivers be merged?

sbergman27 — Tue, 16 Sep 2008 15:13:24 +0000

"""
Greg will take responsibility for getting some of those linux-staging drivers into the mainline; he has, it was suggested, just become the official crap maintainer.
"""

One common complaint about Linux is its lack of support for newer hardware. Never mind that it supports every ISA card ever sold. What people care about is the new stuff that they can buy *now*. It seems to me that the kernel devs consider new drivers, and by extension, the skills of the programmers writing them, to be crap. I'm not sure that attitude will be good for Linux in the long term.

But determining to try to get the stuff into the mainline tree is a positive action, regardless.

KS2008: When should drivers be merged?

lbt — Tue, 16 Sep 2008 13:11:05 +0000

So how does this apply to lirc?