Staging drivers out
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.
| Index entries for this article | |
|---|---|
| Kernel | Staging tree |
Posted Oct 29, 2009 11:48 UTC (Thu)
by nix (subscriber, #2304)
[Link] (3 responses)
Posted Oct 29, 2009 13:48 UTC (Thu)
by jzbiciak (guest, #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.
Posted Oct 29, 2009 13:49 UTC (Thu)
by johill (subscriber, #25196)
[Link] (1 responses)
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?
Posted Oct 30, 2009 0:16 UTC (Fri)
by giraffedata (guest, #1954)
[Link]
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).
That's exactly the question -- whether new Linux will be compatible with old machines.
Posted Oct 29, 2009 18:53 UTC (Thu)
by riddochc (guest, #43)
[Link]
Posted Oct 29, 2009 19:28 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (6 responses)
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.
Posted Oct 30, 2009 10:05 UTC (Fri)
by nix (subscriber, #2304)
[Link] (5 responses)
Posted Oct 30, 2009 10:08 UTC (Fri)
by nix (subscriber, #2304)
[Link] (4 responses)
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.)
Posted Oct 30, 2009 16:00 UTC (Fri)
by bronson (subscriber, #4806)
[Link] (3 responses)
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. :(
Posted Nov 2, 2009 16:22 UTC (Mon)
by nix (subscriber, #2304)
[Link] (2 responses)
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.
Posted Nov 2, 2009 18:06 UTC (Mon)
by bronson (subscriber, #4806)
[Link] (1 responses)
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?
Posted Nov 3, 2009 19:42 UTC (Tue)
by nix (subscriber, #2304)
[Link]
And yes, it *is* better to break it softly and only kill it hard later on.
Posted Oct 29, 2009 21:14 UTC (Thu)
by davecb (subscriber, #1574)
[Link] (2 responses)
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
Posted Oct 31, 2009 18:04 UTC (Sat)
by NAR (subscriber, #1313)
[Link] (1 responses)
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
Posted Nov 5, 2009 18:21 UTC (Thu)
by muwlgr (guest, #35359)
[Link]
Staging drivers out
Staging drivers out
Staging drivers out
Staging drivers out
you have to find at least _two_ machines for it to make sense. ...
If you can even run the latest kernel on that machine ...
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
Staging drivers out
To enable it for this boot only, echo 1 > /proc/sys/kernel/drivers/enable-metricom
If you are currently using this driver, please contact grek-kh@kernel.org
Staging drivers out
Staging drivers out
Staging drivers out
Staging drivers out
Staging drivers out
Staging drivers out
subject line. :)
Jonathan writes: The "staging out" process may not be perfect, but nobody has posted a better idea yet.
Staging drivers out
You increment the minor version number, and ship an updater with the new version that warns the user that the program is going to go out of support, and invites them to volunteer. After a while you bump the minor number and make the user confirm that they know it's going away. Then you bump it once more and make it fail. All over about a 18-month period, just like your normal maintenance.
Staging drivers out
Staging drivers out
Staging drivers out