Re: [RFC][PATCH 5/9] perf trace: Add Perl scripting support

[Frederic Weisbecker <fweisbec@gmail.com>]

On Sun, Oct 11, 2009 at 10:58:46AM +0200, Ingo Molnar wrote:
> 
> * Tom Zanussi <tzanussi@gmail.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


But I think we may want to have some integrated scripts that can
play the role of subcommands when it comes to process
particular trace events. Because this is just about reading binary
traces and put them in a shape that makes sense wrt to the targeted events.

So I think in this particular area we should better choose scripting
languages. If we limit us to the C in this field, we restrict us
in a slow development.

Re-implemeting the workqueue profiler in Python/Perl/Whatever would
take several hours. In C it's several days, with potential security
holes inside...