|| ||Alan Cox <alan-AT-lxorguk.ukuu.org.uk>|
|| ||Linus Torvalds <torvalds-AT-linux-foundation.org>|
|| ||Re: 2.6.24-rc4-git5: Reported regressions from 2.6.23|
|| ||Sun, 9 Dec 2007 22:01:32 +0000|
|| ||Tejun Heo <htejun-AT-gmail.com>,
Andrew Morton <akpm-AT-linux-foundation.org>,
"Rafael J. Wysocki" <rjw-AT-sisk.pl>,
LKML <linux-kernel-AT-vger.kernel.org>, Ingo Molnar <mingo-AT-elte.hu>|
> Btw, Alan, that "math" is total and utter BULLSH*T, and you should know
The one off regression is probably not one off, but this is IDE so
actually its quite probable its a single broken firmware.
The alternative is that you cripple just about every user of various
other standards compliant devices and controllers whose hardware we
Finally you need to remember that the 'regression' is caused by the fact
we now do the _right_ thing both in terms of 'old IDE' and specs.
Believe it or not I did actually think in quite some detail about this
case, and the relative probabilities, and go back and re-review the old
IDE code (whose behaviour we now follow) and the spec. I spend a
measurable amount of my time reviewing code and weighing risks,
regressions and progress for an enterprise Linux vendor, so its something
I do every day of the week.
To blindly argue regressions are critical is sometimes (as in this case)
to argue that "this freeway is no longer compatible with a horse and
cart" means the freeway should be turned back into a dirt road.
The horse and cart happened to work by chance because the road was quiet
that day. We clearly need to add a horse & cart lane in the long term,
but for 2.6.24 it may well be the right thing to do just to blacklist
that specific drive back to old behaviour until we can tidy it more
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to post comments)