Cc: Rafael J. Wysocki <rjw@...>, Benjamin Herrenschmidt <benh@...>, Matthew Garrett <mjg59@...>, <linux-kernel@...>, Pavel Machek <pavel@...>, <linux-pm@...>
On Wed, Jul 04, 2007 at 01:29:49PM +1000, Paul Mackerras wrote:
You forget one important point:
Regressions are much worse than normal bugs.
It's not about the question whether the driver was "correct" or
"buggy" - for a user the important question is whether it worked in
practice, and if yes, whether it continues to work.
And my impression is that every time someone touches some part of the
suspend code some drivers break.
During 2.6.21-rc, it wasn't unusual for users to run with one kernel
into up to three distinct suspend regressions on one machine.
And no, it wasn't always the same set of distinct regressions.
IMHO the suspend code is currently way too much of a moving target which
results in this mess.
The correct order seems to be:
1. agree on what the suspend code as a whole should look like
2. implement this
3. fix ALL drivers to work at least as good as they do today
4. get it tested in -mm
5. fix all bugs people run into
6. submit it for inclusion in Linus' tree
7. quickly work on the most likely big amount of bug reports
Step 1 is the most important one - evolving code is often something
good, but in this case with different people trying to evolve the
suspend code in different directions it simply results in a big mess.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
