Re: [GIT PULL] Performance Counters for Linux

[Steven Rostedt <rostedt@goodmis.org>]

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