| |||||||||||||
Staging drivers outStaging drivers outPosted Oct 29, 2009 19:28 UTC (Thu) by bronson (subscriber, #4806)Parent article: Staging drivers out
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.
(Log in to post comments)
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.
|
|||||||||||||