Weekly Edition
Return to the Kernel page
| |||||||||||||
On the driver life cycle
As a general rule, all new features are supposed to be added to the kernel
during the two-week merge window. There is an exception of sorts, though,
for new device drivers. A well-written driver should not be able to cause
regressions anywhere else in the kernel, and there is often value in
getting it to users as quickly as possible. So drivers will often make it
into the mainline when other large changes are barred.
As the story of the recent SCSI fixes pull request shows, though, there are limits. This request included a pair of new drivers for high-end SCSI storage systems. Linus got grumpy for a few reasons: he would like to see subsystem maintainers try harder to get drivers in during the merge window, he thinks that the "driver exception" is mainly useful for consumer-level devices, and the driver in question here is not small bit of code - it's a 50,000 line monster. In the end, the driver was merged for 2.6.32-rc4, but Linus made it clear that he would rather see this kind of code during the merge window. The conversation drifted into whether the driver should have gone into the staging tree instead; those who looked at it did not describe it as the best code they had seen that day. SCSI maintainer James Bottomley sees the staging tree mainly as the place where user-space ABI issues are cleaned up. Mere code quality issues, he believes, are better handled directly in the SCSI tree. Others disagree; in the end, it will come down to what specific subsystem maintainers want to do. If the maintainer takes a new driver directly into the subsystem tree, nobody else can force it into staging instead. The discussion brought out another potential use for the staging tree - as a last resting place for old drivers on their way out of the kernel. Staging maintainer Greg Kroah-Hartman noted:
It seems that I'm the only one that has the ability to drop drivers
out of the kernel tree, which is a funny situation :)
In thinking about this a lot more, I don't really mind it. If people want to push stuff out of "real" places in the kernel, into drivers/staging/ and give the original authors and maintainers notice about what is going on, _and_ provide a TODO file for what needs to happen to get the code back into the main portion of the kernel tree, then I'll be happy to help out with this and manage it. The idea remains hypothetical, though, until somebody actually uses the staging tree in this manner. It is hard to imagine a demotion to staging that would not be resisted by somebody; the first attempt to do so may well be interesting to watch. (Log in to post comments)
On the driver life cycle Posted Oct 15, 2009 5:33 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
Thank you for spotlighting this issue, the discussion was buried in the middle of a thread that I'll bet a lot of people skipped.
I think the proposal for using staging to try and force maintainers to clean up their code or else have it dropped from the kernel is a very bad idea.
I think that 6-9 months (2-3 releases) is _far_ too short for users to notice. most users will be using a distro kernel that is on a release cycle longer than this (even if they are not using a 'enterprise' distro),
Also, what happened to the desire that Linux would be able to use anything, and once a driver was upstream changes to the kernel that would break it should be fixed by whoever is introducing those changes? This seems to be moving in the direction of only having drivers for fairly current, fairly common hardware.
On the driver life cycle Posted Oct 15, 2009 14:53 UTC (Thu) by arjan (subscriber, #36785) [Link]
increasingly there seem to be a handful of cases where the "he who makes the change fixes the driver" breaks down: If the driver that needs to be fixed is fundamentally broken already, it isn't really an option to "just fix it", since it's not clear, if you don't have/know the hardware, how to go about doing that.
Especially with the recent BKL work this is becoming a problem; some drivers have incredibly broken locking assumptions, and the best the BKL people can do is "it's not more broken than it was before".
Note that this is largely about unmaintained drivers for hardware that does not have much, if any, use... otherwise the serious problems would have been noticed and worked on.
Anyone who would regret such a driver going away can step up to help maintain the driver again, at which point it can even graduate from staging again....
On the driver life cycle Posted Oct 15, 2009 17:43 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
the cases where the drive is already broken is not the issue here.
as for this only being for hardware that does not have much, if any use.. how can the kernel developers know which drivers people are using? how little use does a driver need to have before it's removed?
this isn't being proposed for drivers with serious functional problems, it's being proposed for drivers that are 'ugly', they work, but don't do things the right way.
yes, someone can step in to pick up a driver, they can even recover it from git history if needed, but in the meantime the driver that has been removed is _not_ getting updated with the other changes taking place, so this becomes a problem similar to backporting drivers to earlier kernels (just moving the other direction)
|
|||||||||||||