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 15:43:57 +0200
From:	Borislav Petkov <bp@...64.org>
To:	Arnaldo Carvalho de Melo <acme@...radead.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

From: Arnaldo Carvalho de Melo <acme@...radead.org>
Date: Mon, Jun 14, 2010 at 10:02:01PM -0300

> > > I thought about suggesting using -I to reduce patch size, but then it is
> > > using "" :-\
> > 
> > Yeah, I have the -I$(CURDIR)/lib for this in the top level Makefile so all
> > library includes would be like:
> > 
> > #include <util.h>
> > 
> > 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.

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?

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

Hmm...?

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Gemeinde Aschheim, Landkreis München
Registergericht Muenchen, HRB Nr. 43632
--
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/