| |||||||||||||
ACPI, device interrupts, and suspend statesACPI, device interrupts, and suspend statesPosted Aug 5, 2005 19:03 UTC (Fri) by zblaxell (subscriber, #26385)Parent article: ACPI, device interrupts, and suspend states
There are ways to make progress without so much disruption. Believe it or not, people do notice when the kernel starts spitting out printk messages that it didn't spit out before, especially if those messages describe what has to be changed, or who has to be notified, and if those messages are triggered many times by doing something routine that the user relies on.
Something along the lines of "driver XXX didn't call free_irq before suspend, please fix it" would be nice. I'd even sift through a bunch of "driver XXX _did_ call request_irq after resume" messages to ensure that all the devices in my system were accounted for, and maybe even fix the ones that aren't.
I'd be willing to run the latest kernel on most of my less essential machines, if I could expect the latest kernel to discover and complain about expected future breakage in my specific circumstances, and if I can expect most of the stuff that worked in the previous kernel to work in the next.
On the other hand, if the kernel developers' approach to API and policy changes is to just commit a patch and let everyone else catch up with fixes to things that--although possibly fragile and ugly--were not actually broken in the first place, then I'll only run those kernels when they're well and truly finished (i.e. never), or when I have absolutely no alternative.
(Log in to post comments)
|
|||||||||||||