Re: Look Ma, da kernel is b0rken

[Borislav Petkov <bp@alien8.de>]

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.