lkml.org 
[lkml]   [2004]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] Splitting kernel headers and deprecating __KERNEL__
    On Wed, 01 Dec 2004 01:06:17 +0000, David Woodhouse <dwmw2@infradead.org> wrote:
    > On Tue, 2004-11-30 at 16:57 -0800, Linus Torvalds wrote:
    > > This isn't even a "fix". It's a cleanup. It goes under the same rules
    > > a spelling fix does.
    >
    > So you don't see a long-term technical benefit in cleaning up the
    > API/ABI we export to userspace so that userspace stops depending on
    > stuff which just isn't supposed to be there? It's all just cosmetic
    > masturbation as far as you're concerned? There's no point in trying to
    > get to the point where we don't need to separately maintain a
    > glibc-kernheaders package because it can be taken directly from the
    > kernel?

    There obviously _is_ a technical benefit. And to put out second usual
    argument used to reject patches, this benefit is desirable/matters to
    more than single digit number of users.

    But lets face it, the changes you guies are discussing in this long
    thread are _massive_. May be not so much theorotical mass. In theory
    this is just a trivial movement of text from file to file with new
    rules enforced on adding new text.
    But this does boil down to a great number of user interfaces being
    touched. And as far as the linux engineering practices go, this is
    _huge_.

    The costs are high, each header file change is going to affect
    everything, the regression testing is going to be pain if we actually
    go do the modifications suggested by this thread.

    And lets face it, with a retard[1] chosen as our leader , _mistakes
    will happen_. Things will _break_ and any decision taken will more
    often be a false one.

    But we already know a better way to do things. After all thats how we
    have taken linux to the place where it is today. We can just start
    making the changes. In small steps. See if anyone is really bothered
    by the change. See if enough people give you feedback so that you are
    bothered to propagate the change to newer level.

    I would much rather like to see the glibc-kernelheaders shrunk by few
    bytes every 3-4 months or so. And yes this actually has a chance that
    it may never happen.

    The whole "put forward an idea get a consensus" and then "try to
    engineer it" works well for theory. But not in practise. In the end,
    only the good things prevail not because they were created good, but
    more because bad things can't servive. Leave the whole idea of "putting
    a research together and try to do the ultimate right" for the FreeBSD
    team.

    And don't try to do the ultimate right without any reasearch, thats
    microsoft's domain.

    In summary, splitting the headers could be a good idea. But to have
    any acceptance you need to prove it by practical examples. And when
    you do new things, be prepared to accept that they might fail in
    practise.

    BAIN

    [1]see:
    http://marc.free.net.ph/message/20041109.161141.2f4e1246.html
    -
    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: 2005-03-22 14:08    [W:3.593 / U:0.228 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site