On Sat, Dec 08, 2012 at 08:36:34AM +0100, Andreas Mohr wrote: > And that demand actually applies to both the '@' change (questionable) > and the much less disputed (obviously correct) wrong conditional > fixup, since both introduce a notable change (either large, or > possibly improper) in behaviour. Well, I think Alan's fix is obviously correct and doesn't necessarily need confirmation. But it will have ~3 months verification time in 3.8, just in case. > > So the actual practical question turns into: do you have such > > hardware to verify your or anyone else's fix on? > > Not the ALS100 (only ALS4000 here). I possibly have some other > ISA hardware, but probably none which contains '@' data in their > PnP id struct. The driver for the well-known case of ISDN PnP > cards does not seem to contain it. However ISTR that CMI8330 was > quite widespread (did I have one? Do I??). For identification, see > http://www.yjfy.com/C/C-Media/soundchipset/CMI8330A.htm > > I'm afraid I should get an old system back up and running, exactly for > such validation work cases (and perhaps so should a select few other > developers, too). > > BTW, "my" fix? I thought that everybody had come to the conclusion by > now that I merely pointed out (in no uncertain terms to boot) that > something was broken :) Ok, here's the deal: we can blubber about fixing bugs in the kernel and whether it needs this and that forever, but at the end of the day, Linux is scratching an itch. That's it. There are no contracts, affirmations or whatever. IOW, if it is not itching you strong enough, you won't scratch it. All I'm saying is, there are bugs and bugs. If this is a bug in a piece of hardware which no one uses anymore and it might be violating the spec or not, whatever, who cares..., but we can't verify that anymore, then we leave it as is. There's absolutely no reason to touch this code and so we'll let it die a peaceful death. Now, if your box doesn't boot or something else annoys you strong enough (the itch), then you can try fixing it (the scratch), or involve someone more knowledgeable if you cannot do it yourself. In any case, if you decide to fix anything though, you better do it right. Thus the requirement to verify the fix on a real hardware. So to answer your initial rant: yes, like any other non-trivial piece of software, there are bugs in the kernel too. And yes, we always try addressing the most important ones as fast as possible. And I'm sure you know the kernel's track record of fixing bugs in a lightning fast manner. The other, not-so-important, not-so-critical bugs get "delayed" sometimes. :-) That's the whole deal. -- Regards/Gruss, Boris. -- 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
