Weekly Edition
Return to the Kernel page
| |||||||||||||
Staging drivers out
The staging tree was conceived as a way for substandard drivers to get into
the kernel tree. Recently, though, there has been talk of using staging to
ease drivers out as well. The idea is that apparently unused and unloved
drivers would be moved to the staging tree, where they will languish for
three development cycles. If nobody has stepped up to maintain those
drivers during that time, they will be removed from the tree. This idea
was discussed at the 2009 Kernel Summit with no serious dissent.
Since then, John Linville has decided to test the system with a series of ancient wireless drivers. These include the "strip" driver ("STRIP is a radio protocol developed for the MosquitoNet project - to send Internet traffic using Metricom radios."), along with the arlan, netwave, and wavelan drivers. Nobody seems to care about this code, and it is unlikely that any users remain. If that is true, then there should be no down side to removing the code. That hasn't stopped the complaints, though, mostly from people who believe that staging drivers out of the tree is an abuse of the process which may hurt unsuspecting users. It is true that users may have a hard time noticing this change until the drivers are actually gone - though their distributors may drop them before the mainline does. So the potential for an unpleasant surprise is there; mistaken removals are easily reverted, but that is only partially comforting for a user whose system has just broken. The problem here is that there is no other way to get old code out of the tree. Once upon a time, API changes would cause unmaintained code to fail to compile; after an extended period of brokenness, a driver could be safely removed. Contemporary mores require developers to fix all in-tree users of an API they change, though, so this particular indicator no longer exists. That means the tree can fill up with code which is unused and which has long since ceased to work, but which still compiles flawlessly. Somehow a way needs to be found to remove that code. The "staging out" process may not be perfect, but nobody has posted a better idea yet. (Log in to post comments)
Staging drivers out Posted Oct 29, 2009 11:48 UTC (Thu) by nix (subscriber, #2304) [Link]
This does mean that if you have an old machine with obscure hardware and want to be sure it's not silently dropped, you *have* to run upstream kernels or watch LKML: distributor kernels won't cut it. (They probably don't build modules for obscure hardware, so you probably have to do that anyway.)
Staging drivers out Posted Oct 29, 2009 13:48 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link] I wonder if it makes sense to have an "CONFIG_ENABLE_DEPRECATED_DRIVERS" to hide these guys behind once they start down this "staging out" path. ie. do something so that anyone trying to run a deprecated driver is more likely to notice that their driver is (potentially) going away.
Staging drivers out Posted Oct 29, 2009 13:49 UTC (Thu) by johill (subscriber, #25196) [Link]
If you can even run the latest kernel on that machine ...
Also, for the wireless drivers in question, you have to find at least _two_ machines for it to make sense. And then I suspect not all drivers support ad-hoc mode or whatever it was at the time, so maybe you even have to find an AP for them?
Staging drivers out Posted Oct 30, 2009 0:16 UTC (Fri) by giraffedata (subscriber, #1954) [Link] you have to find at least _two_ machines for it to make sense. ... I don't think the concern is that someone will have a wireless card in a closet for ten years and then decide to build a system with it. It's that someone has a system running continuously for ten years using that wireless card, which means he also has other machines and APs as required, and then suddenly wants to switch to a new Linux kernel to add a feature. It would be nice if he didn't have to choose between the new kernel-provided feature and the old wireless card (and probably a dozen other old components that are tied to it). If you can even run the latest kernel on that machine ... That's exactly the question -- whether new Linux will be compatible with old machines.
Staging drivers out Posted Oct 29, 2009 18:53 UTC (Thu) by socket (guest, #43) [Link] I remember using Metricom's ricochet modems. Way before its time - the range (if not the speed) you could get from them was pretty impressive. I wish they had survived.
Staging drivers out Posted Oct 29, 2009 19:28 UTC (Thu) by bronson (subscriber, #4806) [Link]
What about intentionally breaking the drivers for a few releases?
When a deprecated driver is loaded, it could log:
WARNING: the metricom driver is deprecated and has been disabled!
That way kernel users would get adequate warning before a driver goes away completely and kernel devs could confirm that nobody cares enough about keeping it to even send an email.
It does mean that you need to upgrade the kernel on your obsolete hardware every few years. That seems reasonable. If you don't, then you don't care what's happening in new kernels anyway.
Staging drivers out Posted Oct 30, 2009 10:05 UTC (Fri) by nix (subscriber, #2304) [Link]
Yeah, but if people can't keep CONFIG_DEPRECATED or feature-removal-schedule.txt up to date, why is this any more likely to work? Now the users have to check *three* ways of seeing if something is out of date, and if they miss one, we can blame them for not looking at it! Isn't that fun?
Staging drivers out Posted Oct 30, 2009 10:08 UTC (Fri) by nix (subscriber, #2304) [Link]
Sorry, *four* ways. There's also drivers that emit clear deprecation messages in the kernel log.
On one of my machines, booted daily, I'd been getting deprecation messages for one feature for months, but I never noticed it because it was lost among several hundred Kb of mostly-boring messages which flashed past far too fast to read, and it was so long it overshot the dmesg buffer (I hadn't noticed it grow to overflow the buffer in the last few releases). And I'm a bleeding-edge kernel user. How are random users supposed to be able to handle this?
(Kernel boot message volume on SMP is being reduced, a bit. Good.)
Staging drivers out Posted Oct 30, 2009 16:00 UTC (Fri) by bronson (subscriber, #4806) [Link]
This is more likely to work because it actually breaks your driver. You're guaranteed to notice! And it makes it very easy to unbreak the driver so you're not utterly screwed when it happens to you.
Agreed, emitting deprecation warnings into the kernel log is equivalent to doing nothing. Who reads the entire kernel log anymore? And dumping warnings into feature-removal-schedule.txt is just as bad since nobody reads that either. Maybe these techniques should be deprecated themselves. :(
Staging drivers out Posted Nov 2, 2009 16:22 UTC (Mon) by nix (subscriber, #2304) [Link]
So... you consider breaking a network driver and breaking headless machines completely, possibly requiring long cross-country treks to fix it, a *good* thing?!
Upgrading the kernel frankly scares me now. Every single kernel from 2.6.28.x upwards has hit me with at least one severe regression on my home machines alone (defined as 'prevents booting or disrupts normal functioning on an at least daily basis'), and there are only four of them and a few VMs! When I upgrade I now schedule a whole weekend to try to work around the inevitable blasted breakages... even upgrading glibc is less nervewracking.
Staging drivers out Posted Nov 2, 2009 18:06 UTC (Mon) by bronson (subscriber, #4806) [Link]
Jeez, are you deliberately trying to be difficult? When did I ever say that?
We're talking about staging drivers out here. In other words, BREAKING THE DRIVER. We just need to figure out how to do it with the least amount of distress to end users.
I claim that breaking the driver softly, then removing it a year later, is better than just yanking it out without warning. And that the current technique of emitting log messages and adding entries to text files that nobody reads are more or less equivalent to doing it without warning.
Does that make sense?
Staging drivers out Posted Nov 3, 2009 19:42 UTC (Tue) by nix (subscriber, #2304) [Link]
Ah. Er, yes, true. I lost the context somewhere, despite it being in the
subject line. :)
And yes, it *is* better to break it softly and only kill it hard later on.
Staging drivers out Posted Oct 29, 2009 21:14 UTC (Thu) by davecb (subscriber, #1574) [Link] Jonathan writes: The "staging out" process may not be perfect, but nobody has posted a better idea yet.Actually the usual process dates back to before Unix, so probably you young whippersnappers just aren't old enough to remember it (;-)) It's a special case of the process described in Paul Stachour's continous maintenance talk, at http://queue.acm.org/detail.cfm?id=1640399#at
To be fair, people who maintain linkers will probably know this trick: it's how they commonly handle format changes. --dave (who helped Paul polish the paper) c-b
Staging drivers out Posted Oct 31, 2009 18:04 UTC (Sat) by NAR (subscriber, #1313) [Link]
It only works if the users upgrade always to every new release - which is not the case with the kernel, even the 6-montly distribution releases are bound to miss at least one of the 3-montly kernel releases, not to mention the Debian stable users...
Staging drivers out Posted Oct 31, 2009 19:57 UTC (Sat) by davecb (subscriber, #1574) [Link] Not necessarily: unwillingness to upgrade and the freedom to not upgrade is why the time periods are so long. In the commercial world, the rule of thumb is that the slower users upgrade every three years, because the hardware turns over in roughly that period. Instead of the months I usually work with, large-systems and linkers folks tend to support old versions of things for multiple hardware cycles, with complaints in the current, forced user intervention in the second and obsolescence in the third if no-one or note enough people scream bloody murder in the first two. --dave
Staging drivers out Posted Nov 5, 2009 18:21 UTC (Thu) by muwlgr (guest, #35359) [Link]
Yes, please move this newer (but long broken) pata_pdc202xx_old driver there, just to tell Fedora and Ubuntu distributions to give users older but working pdc202xx_old one.
|
|||||||||||||