Re: [GIT PULL] Performance Counters for Linux

[Pekka Enberg]

On Thu, 11 Jun 2009, Christoph Hellwig wrote:
>> So what point is there in keeping it in-tree except making life hell for
>> packagers?

On Thu, Jun 11, 2009 at 8:06 PM, Linus
Torvalds<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> Give it up. Packagers can trivially generate their own sub-packages. They
> do it all the time. They already do it for the user-mode header files,
> extracted from the kernel - something you've worked on yourself.
>
> So your point is clearly bogus, and dishonest.
>
> You haven't actually looked the real problem in the eye, and acknowledged
> the disaster that is oprofile. Let's give a _new_ approach a chance, and
> see if we can avoid the mistakes of yesteryear this time.

Yup, I wonder what all the fuzz is about. We already have userspace
tools in the kernel but people keep putting them under Documentation
(to avoid this discussion, probably).

For those who think an external repository is a good idea, I invite
you to compare the success of kmemtrace (kernel memory profiler) and
perf. The former has its userspace part out-of-tree and has gained
zero new developers. Sure, there are probably fewer people interested
in memory profiling and I or Eduard surely don't have the sex appeal
of Ingo Molnar (yet anyway). But even if you take these factors into
account, I'd argue that big part of the success has been the fact that
it's easily accessible and hackable. And that pretty much means that
the code needs to sit in the kernel tree, following kernel development
process.

And really, what do we gain by moving perf out of tree and making it
follow its own release cycle (and getting out of sync eventually)?

                        Pekka
--
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/