Messages in this thread |  | | | Date | Thu, 11 Jun 2009 17:59:41 -0400 | | From | Steven Rostedt <> | | Subject | Re: [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
|  |