lkml.org 
[lkml]   [2009]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT PULL] Performance Counters for Linux
    Sam Ravnborg wrote:
    > On Thu, Jun 11, 2009 at 09:26:55AM -0700, Linus Torvalds wrote:
    >>
    >> On Thu, 11 Jun 2009, Christoph Hellwig wrote:
    >>> Err, no. This adds tons of userspace code into tools/ which
    >>> should not be in the kernel tree but a proper package.
    >> I disagree.
    >>
    >> We've had tons of cases where we tried to "separate" the user-land code
    >> and the kernel code, in the name of "beauty" of whatever.
    >>
    >> It's almost invariably a disaster.
    >
    > This is cheating. I had this as a topic for the kernel summit and
    > was looking forward to read an interesting article about people
    > dancing on the table and fighting in the corners about it.
    > [I do not attend myself]
    >
    > People say that this would be a nightmare for the packagers.
    > I frankly do not see what the issue is here.

    Kernels don't fit well in distribution models.
    We have distribution since 15 (and more) years, but still with
    hackish support for kernels.

    Kernel:
    - people are used to install multiple "parallel" kernels
    - from different sources (distribution, kernel.org)
    - and a lot of people configure own kernel

    This is a lot different of usual packages:
    - packages have dependencies (done at pre-installation time)
    - packages normally support only upgrades (and not downgrades)
    - support for multiple version exist only on libraries (SONAME)

    Thus a program could depends on specific version of the libc,
    but it cannot depends on a specific kernel (system doesn't know
    the kernel of next boot), which requires a lot of hack in init.d
    scripts.

    BTW one of the most frequent question on distribution was
    about configuring the kernel and the error about missing
    lib[n]curse[X]-dev[el].

    So the 15 year without finding a good solution could explains the
    nightmare, (but it could be finally the opportunity to really
    solve the problem).

    To conclude: a user space program should not only have a stable
    ABI, but also have nice messages about unsupported features
    (and wrong kernel) and not changing runtime dependencies like
    socks.

    ciao
    cate


    \
     
     \ /
      Last update: 2009-06-15 15:59    [W:3.437 / U:0.304 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site