lkml.org 
[lkml]   [2006]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: 2.6.16-rc4: known regressions
    From
    Date
    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-02-22 17:21    [W:5.454 / U:0.156 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site