Re: [GIT PULL] Performance Counters for Linux

[Robert Richter]

On 11.06.09 12:49:25, Linus Torvalds wrote:
> 
> 
> On Fri, 12 Jun 2009, David Newall wrote:
> 
> > Linus Torvalds wrote:
> > > To take the oprofile example that decided it for me: the code to actually 
> > > support new processors was all done by basically kernel developers. And it 
> > > didn't hit user land for almost a year, because the user-land tools didn't 
> > > take the patch and propagate it up.
> > 
> > Bad developer, Spot, you only did half the job. Not sure there's much
> > more one can say.
> 
> Umm. The kernel developer _did_ do the job. The patch to the user land 
> side was available for that whole year. It just didn't get merged, and 
> then didn't get merged some more, and then got merged but only in a SVN 
> tree, not a release, and then finally when I did a bugzilla request to 
> fedora, they took the patch and put it in their distro.

Having the oprofile user land in the kernel would not solve the
problem. Then you would have code in the kernel tree you actually
don't wont there: XML encoder, autoconf scripts, graphical tools, c++
code, man page docs, etc., and maybe different coding style.

The problem is another one. First, as Christoph mentioned, it is a
design problem of oprofile. Changes in the kernel require user land
changes. This could be done better, but everybody knows it is hard to
change the user/kernel i/f and maybe, keep backward compatibility
too. So this is not easy to fix.

Second, there are different users with different expectations. (Linus,
I suggest oprofile has one user less, hmm...) Some run the latest
kernel on the latest systems, others use it in their clusters using
stable, not often changing well tested releases and hardware. If a
user land release aims more the seconds, it must conflict with the
others. Also, being in sync with the kernel would require release
cycles as for the kernel, which was the problem here with oprofile.

But, user land patches exist, even at the day of the kernel
release. Otherwise the code would have been badly or not tested. And
the patches are also in a repository, _somewhere_. This, was true for
oprofile too, the patches were in cvs at least on the day the kernel
was released. (I think a git repository would be nicer, but that's a
different question.) And this is the next problem, the patches are
somewhere, sometimes not under control of the kernel developer. And
this could be best solved if the kernel developer who brings the
kernel code upstream maintains a user land repository at
git.kernel.org.  (Marcel already suggested this too.) There could be
all patches in required to run the latest kernel, based on the latest
user land release. (You can blame then the kernel maintainer, if
something does not work.) And of course the user is required then to
compile the user land himself, as he does for the kernel. And maybe,
distros pick up the patches too when adding a new kernel to it.

So, I think this would be much nicer than having a user land in the
kernel tree. And this would also solve the problems with the oprofile
user land.

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter@xxxxxxx

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/