lkml.org 
[lkml]   [2009]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT PULL] Performance Counters for Linux
    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.

    We should be able to add the necessary stuff to create the few popular
    package formats.
    And tools like kernels may update 4 times/year with ease - so the kernel
    release frequency should be a non-issue too.

    Others just say "no userspace in the kernel" - and I honestly have not understood why.


    Where to draw the line?
    We can ask a few simple questions:
    - Are the tool part of a kernel hackers toolbox?
    - Are the tool maintained by kernel people?
    - Are the tool updated with new features in the kernel (*)?

    If the answer is yes it is a good candidate.

    (*) No excuse for ABI changes..


    Simple example. I needed vmstat on my embedded platfrom the other day.
    Got lots of hits on google but could not find the source - and gave up as I was busy.
    [Today I found it in second try - sigh.]

    Sam


    \
     
     \ /
      Last update: 2009-06-11 20:51    [W:5.517 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site