[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091011085846.GF14995@elte.hu>
Date: Sun, 11 Oct 2009 10:58:46 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Tom Zanussi <tzanussi@...il.com>
Cc: Christoph Hellwig <hch@...radead.org>,
linux-kernel@...r.kernel.org, fweisbec@...il.com,
rostedt@...dmis.org, lizf@...fujitsu.com
Subject: Re: [RFC][PATCH 5/9] perf trace: Add Perl scripting support
* Tom Zanussi <tzanussi@...il.com> wrote:
> On Wed, 2009-10-07 at 10:13 -0400, Christoph Hellwig wrote:
> > On Tue, Oct 06, 2009 at 11:09:25PM -0500, Tom Zanussi wrote:
> > > > I think we also want to have a 'perf -s *' kind of thing to get a list
> > > > of all available language modules.
> > > >
> > >
> > > I knew somebody would point that out (and suggest a better way ;-) That
> > > all makes sense - I'll make these changes in the next version.
> >
> > I'm a bit worried about linking two million scripting language into the
> > main perf binary. Can't we just have seaprate perlperf / pythonperf,
> > rubyperf, awkperf binaries that only contain the scripting support?
>
> Yeah, that's a good point. [...]
No, we want to keep a single core binary, it has many advantages. Git
has gone through a very painful conversion from many spread out git-*
commands back into a central binary. So we avoided that mistake in perf
from the get go. We are not going to add separate perf-* commands.
ad-hoc extensions using separate perf-* scripts are fine of course and i
use that myself. But once a facility is part of core perf it wants to
move into the binary. Especially something as central as scripting
support.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists