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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091011121630.GC4901@nowhere>
Date:	Sun, 11 Oct 2009 14:16:32 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Tom Zanussi <tzanussi@...il.com>,
	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org, rostedt@...dmis.org,
	lizf@...fujitsu.com
Subject: Re: [RFC][PATCH 5/9] perf trace: Add Perl scripting support

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


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...

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