Re: 2.6.16-rc4: known regressions

[David Zeuthen]

On Wed, 2006-02-22 at 07:44 -0800, Linus Torvalds wrote:
> 
> On Wed, 22 Feb 2006, Kay Sievers wrote:
> > 
> > Well, that's part of the contract by using an experimental version of HAL,
> > it has nothing to do with the kernel
> 
> NO NO NO!
> 
> Dammit, if this is the logic and mode of operation of HAL people, then we 
> must stop accepting patches to the kernel from HAL people.
> 
> THIS IS NOT DEBATABLE.
> 
> If you cannot maintain a stable kernel interface, then you damn well 
> should not send your patches in for inclusion in the standard kernel. Keep 
> your own "HAL-unstable" kernel and ask people to test it there.

Oh, you know, I don't think that's exactly how it works; HAL is pretty
much at the mercy of what changes goes into the kernel. And, trust me,
the changes we need to cope with from your so-called stable API are not
so nice. 

But I realize these changes are important because it's progress and back
in 2.6.0 things were horribly broken for at least desktop workloads [1].
It also makes me release note that newer HAL releases require newer
kernel and udev releases and that's alright. In fact it's perfectly
fine. We get users to upgrade to the latest and greatest and we keep
making good progress. That's open source at it's finest I think.

For just one example of API breaking see

 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175998

This breaks stuff for end users in a stable distribution. Not good.

> It really is that easy. Once a system call or other kernel interface goes 
> into the standard kernel, it stays that way. It doesn't get switched 
> around to break user space.
> 
> Bugs happen, and sometimes we break user space by mistake. Sometimes it 
> really really is inevitable. But we NEVER EVER say what you say: "it's 
> your own fault". It's _our_ fault, and it's _our_ problem to work out.
> 
> Guys: you now have two choices: fix it by sending me a patch and an 
> explanation of what went wrong, or see the patch that broke things be 
> reverted. And STOP THIS DAMN APOLOGIA. 
> 
> I'm fed up with hearing how "breaking user space is ok because it's HAL or 
> hotplug". IT IS NOT OK. Get your damn act together, and stop blaming other 
> people. 

I think maintaining a stable syscall interface makes sense. Didn't you
once say that only the syscall interface was supposed to be stable? Or
was that Greg KH? I can't remember...

And I also think that breaking things like sysfs can be alright as long
as you coordinate it with major users of it, e.g. udev and HAL. Please
realize how useful the changes sysfs changes from 2.6.0 to present were
and... and that there still is a lot of work left to make certain things
work for desktop workloads.

I even think changing things like in the RH bug I linked to above is
fine provided that you mentioned it in the release notes...

One day perhaps sysfs will be "just right" and you can mark it as being
stable. I just don't think we're there yet. And I see no reason
whatsoever to paint things as black and white as you do.

    David (Please keep me Cc'ed, I can't keep up with lkml)

[1] : plug in a USB hub with other hubs attached and 10-20 USB devices;
works a lot better with current kernels and udev than it ever did in
2.6.0 with /sbin/hotplug (fork bomb)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/