linux-kernel - Re: [PATCH 1/2] perf: Add persistent events

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]

Date:	Thu, 17 Jun 2010 11:25:46 -0300
From:	Arnaldo Carvalho de Melo <acme@...radead.org>
To:	Borislav Petkov <bp@...64.org>
Cc:	Borislav Petkov <bp@...en8.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Lin Ming <ming.m.lin@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] perf: Add persistent events

Em Thu, Jun 17, 2010 at 03:43:57PM +0200, Borislav Petkov escreveu:
> From: Arnaldo Carvalho de Melo <acme@...radead.org>
> Date: Mon, Jun 14, 2010 at 10:02:01PM -0300
> > > however, this does not differentiate perflib (let's call it that for how
> > > :) from libc headers. Do we want a "perf" or "kernel" or "perflib" or
> > > whatever prefix here - it might make sense later when this thing grows
> > > to differentiate between the namespaces...?

> > Agreed, but the last name this thing will have will be 'perf'something :-)
> > One of the goals at least I have with pursuing this path is to separate
> > out everything that is not strictly 'perf' into things that can be reused
> > by other tools, like yours.

> I'm still splitting perf/util into a more or less generic lib.  Now, I
> want to reuse as much code as possible and am parsing the
> "mce:mce_record" tracepoint using parse_events(). However, this means
> that I have to push the not-so-generic perf bits like
> util/parse-events.c into the lib. Which, in turn, pulls in
> util/trace-event* etc.

I'm not that familiar with the trace bits in perf, but I'd say pick what
is needed for your tool and stash it into files in a tools/lib/trace/
directory, in a way that can be used by both perf and your tools.

I.e. no need to move files as-is, you can reorganize things to make it
useful for both perf and your tool.
 
> What is your preference, do we want to export all perf/util stuff for
> other tools to use or rather link other tools together with
> compilation modules from perf/util in case those other tools need
> them?

If we do it on a as-needed basis, as I suggested, we go eroding the
current perf hodgepodge of potentially generic stuff.
 
> I'm leaning towards the first one and am thinking "maximize code reuse"
> but I'm not completely sure, there might be reasons against it...

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