On Mon, 2008-02-18 at 19:26 -0500, Theodore Tso wrote: > On Tue, Feb 19, 2008 at 01:00:59AM +0100, Thomas Renninger wrote: > > > > Most stuff that gets fixed by these workarounds would make no sense to > > backport, because backports are much too intrusive, e.g.: > > Many of the workarounds really aren't that hard to backport, It's not about how hard, it is about the risk. And you never want to backport e.g. AML fixes in the very heart of the interpreter. Even Intel run it through all their verification suites it will break the one or other certified machine. If instead a small junk of AML code can be written and the vendor embeds it, in a for him safe "if(linux)" environment... that would be cool. For the vendor and for the distributions, not needing another quirk/blacklist whatever ugly hack. > and the > reality is after the distro locks down their kernel version in stone, > and people start complaining about buggy support for the X300 laptop, > or some such, the temptation will be *very* high to put in special > hacks in the thinkpad_acpi driver for some bleeding edge new laptop by > backporting code from a newer kernel, or grabbing a patch which is > being discussed on the linux-thinkpad list, etc. This is about support, right? The thing Len is always propagating which is so important for distributions... The ThinkPad drivers backports are huge. I didn't take the backports because of this. The thinkpad driver is not that important..., newer models should work and it only affects the thinkpad driver, the some thousand line changes will break some machines for sure and regressions is the worst thing to have after a product came out. But maybe this is even doable for e.g. 10.3. A backport of AML fixes affecting every machine is impossible to do in an update for RedHat or SUSE Enterprise products or whatever really stable release is impossible to do. Next point: E.g. evaluation of whether to take 7 or 15 brightness levels is a dirty hack. In fact most of the Thinkpad driver is a dirty hack. Now that vendors care about supporting the systems, why not moving dirty hacks into the BIOS? > So I don't think it's a good idea to assume that a single kernel > version string such as 2.6.25 will have any reliability whatsoever > about identifying what sort of driver workarounds might or might not > be present given a particular distribution or custom kernel compiled > by a user. (I normally pull in the acpi test tree into my kernels, so > often my "2.6.25" kernel will have stuff that might not show up until > 2.6.26.) A vendor sells a machine pre-loaded with a specific product which is bound to a specific kernel! Do you pay money if your kernel breaks machines at least for regressions? Ok you at least take customer calls or better mails :) ... Thomas - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
