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 11:17:16PM +0200, Marcel Holtmann wrote:
    > Hi Sam,
    >
    > > > So you are saying that only good code comes from including it into
    > > > linux-2.6.git and otherwise you will never get there. Have you actually
    > > > tried to maintain this in a separate repository on kernel.org?
    > >
    > > Could you please remind us what the arguments agains including a few
    > > seleted tools within the kernel source tree was.
    > >
    > > I ask because I really cannot see why so much nosie is generated?
    > > As a naive user that like easy access to the stuff I work with
    > > this looks like an optimal place to find the kernel-hacking
    > > tools I need. Why should I hunt somewhere else to find it?
    >
    > I personally would expect a perf.git on kernel.org for the userspace
    > tools for it. Like we have udev.git there, iproute2.git and others.
    >
    > Seems to be working perfectly fine (except of course oprofile) and makes
    > packaging and security updates a lot easier. The distros have always a
    > really hard problem with releasing new kernel packages. And as long as
    > the source changes the whole set of binary packages needs to be rebuilt
    > and in theory if you install a new kernel, you should reboot. So if
    > there is an issue in perf userspace, then the current processes in most
    > distros will propose the user a reboot for no good reason.
    >
    > There is nothing wrong with trying something new, but to be honest I
    > don't buy into the arguments why we do it. It seems like it is all based
    > on bad experience with some userspace maintainers and not really
    > technical grounds why it is a must to have this inside the kernel source
    > code. Of course you can make the argument the other way around and say
    > why not. And I give Linus that he wants to try. However all the
    > arguments from Ingo are a joke and basically tells that all userspace
    > developers have no clue and can't get right anyway.

    Here's another point that I have not really seen anyone make. The tools that
    would be packaged with the kernel are the ones that I would expect the average
    kernel developer to use. Things to help us in developing better code.

    The tools you mentioned

    "ip, iw, rfkill, crda, the WiMAX"

    I have no idea what they do. I don't think I would use them as I don't
    work on bluetooth, and I don't see how they would help me with what I do
    work on.

    I use 'udev' only to boot my machine, and I only notice it when it doesn't
    work.

    As for something like perf, that is something I can see myself using to
    analyze my own code. And I can see other developers (even you) using it for
    the same purpose. This is a tool that I would like to have the latest version
    for the latest version of the kernel I am developing on. That is, if the
    latest kernel had a new feature that perf can take advantage of, it would be
    nice to have it with the new kernel I just pulled.

    This could also work with a perf.git, but I would probably not bother with
    it if I had to keep checking the perf.git repo to see if it uses the
    new features that are in the kernel. I constantly do 'git pull' for the
    kernel and I would get the latest perf with the latest kernel and I
    would not need to bother checking someplace else.

    Actually, I can also see that if a new feature in the kernel was added that
    perf uses, I would probably notice it first with compiling perf and doing
    a perf --help.

    >
    > Maybe it is just a sneaky attempt to get a higher hit in Greg's
    > statistics by just writing some userspace code which otherwise would not
    > be counted ;)

    No, that would be something that I do ;-)

    /me plans on sending patches for perf.

    -- Steve



    \
     
     \ /
      Last update: 2009-06-12 00:03    [W:0.039 / U:32.524 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site