Moving the -staging tree

Greg Kroah-Hartman was tagged as the "maintainer of crap" at this year's Kernel Summit for his willingness to shepherd drivers of lower quality into the mainline. He has not shrunk from that label, when introducing a patch set that would merge some of those drivers. In fact, he has embraced the label: as part of his patch, he introduced the TAINT_CRAP flag for use in tainting kernels that load these, well, crappy drivers.

There has been an ongoing struggle between those who want to see drivers get included as quickly as possible versus those who want to see them approach or attain normal kernel quality levels first. Kroah-Hartman started the -staging tree last June as a way to increase the visibility, thus testing and bug fixing, of out-of-tree drivers. Because drivers in that tree have been steadily improving—to the point where several have graduated to the mainline—the belief is that moving -staging itself into the mainline kernel will result in even faster progress.

So, Kroah-Hartman has introduced a new directory (drivers/staging) to hold these drivers, as well as a mechanism to automatically taint the kernel if any of them get loaded. That will warn users when loading the module—at least if they check their logs—and include that info in any oops message that kernel might produce. Kernel hackers can then filter out problems depending on what the taint is—problems in kernels tainted with binary-only drivers are generally actively ignored.

Getting those drivers into the mainline, though, will make it much easier for folks who want to test them. In addition, clean-ups and fixes for the drivers will go in as mainline patches, raising the visibility of the developers working on them. The change should have very minimal impact on other kernel users and developers. In particular, developers will not have to worry about reflecting API changes into drivers/staging as Kroah-Hartman will keep them up-to-date.

The main complaint about the proposal has been that it duplicates the functionality or intent of the EXPERIMENTAL flag. There was also some belief that tainting the kernel was unduly harsh, but as Kroah-Hartman points out: "It isn't costing anything, and if a developer doesn't want to debug the kernel if such a driver is loaded, this allows them to do this."

As part of the thread, Paul Mundt explains why EXPERIMENTAL has no meaning in the kernel today:

Mundt goes on to show the default configurations almost all enable CONFIG_EXPERIMENTAL, further reducing its meaning. It would be nice to audit all of the uses and restore the meaning of the flag, but that is beyond the scope of what Kroah-Hartman has set out to do. There still would be a difference, though, even if EXPERIMENTAL were meaningful. Mundt continues:

There are still some who are concerned about adding less-than-kernel-quality code. Randy Dunlap puts it this way: "I think that we have enough quality problems without adding crap." But, Linus Torvalds has always been solidly in the "merge early" camp, so this proposal seems likely to go in for 2.6.28. Besides, as Stefan Richter notes:

In a fairly short span of time, merging drivers into the mainline has gotten a whole lot easier. At one time, developers might have to work on a driver for several development cycles before it reached a quality level that would allow it to be merged. In the interim, the -staging tree made things easier and more visible for testers and developers; soon that visibility will rise substantially again.