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  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:	Mon, 6 Oct 2014 15:44:16 +0200
From:	Jean Pihet <jean.pihet@...aro.org>
To:	Robert Richter <rric@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Borislav Petkov <bp@...en8.de>, Jiri Olsa <jolsa@...hat.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Fu Wei <fu.wei@...aro.org>, David Ahern <dsahern@...il.com>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: perf & rasd integration plan

Hi,

On 6 October 2014 11:07, Robert Richter <rric@...nel.org> wrote:
> On 30.09.14 10:24:16, Arnaldo Carvalho de Melo wrote:
>> Em Tue, Sep 30, 2014 at 11:06:21AM +0200, Jean Pihet escreveu:
>> > The plan is to move the small and generic functions first: util,
>> > xyarray, cpumap, thread_map etc; then evlist, evsel, trace-event,
>> > trace-event-parse; and finally integrate rasd into the tools/ dir.
>> >
>> > Any thought? Can evlist, evsel etc. be moved at once?
>> >
>> > Patches should come soon, when time allows.
>>
>> Why don't you add it to tools/rasd/ and in tools/rasd/Makefile you just
>> go on and add tools/perf/util/evlist.o et all to be linked directly, as
>> a first step.
>>
>> Then, as a second step, we can create a tools/lib/perf/evlist.c having
>> what is currently used by both tools/perf/ and tools/rasd/, i.e. what is
>> proven to be useful for something other than perf.
>
> It would be good to have tools/lib/perf or so with some base
> implementation to setup and connect to perf buffers. This is useful
> for tools not only in tools/. The rasd would be a good reference for
> this regardless if it is in tools/ or not. I am not sure whether and
> when rasd will be moved there.

Agree. Having a lib (or a set of libs) that external tools can use is
a must. This will encourage tools developers to use this API instead
of re-invening the wheel every time, and to provide standard tools
that can be merged in the kernel source if needed.

>
>> As the need arises, we go on moving things into tools/lib/perf/evlist.c
>> et all from wherever it appeared first, be it from tools/rasd/,
>> tools/perf/util/evlist.c or anywhere else.
>>
>> Initial rule being that once it is used by multiple tools living in
>> tools/, then it deserves a place in tools/lib/perf/.
>
> So this wouldn't quite work well as it excludes tools not in tools/.
Ditto

I am willing to propose a first set of patches to factor out the
common code from perf, but an agreement is needed on the direction to
take.
My plan is to provide patches for the proposed integration plan (as in
the initial e-mail), is it worth doing so or is it purely wasted time
and effort?

What do you think?

Thx,
Jean

>
> -Robert
>
>>
>> Ditto for other stuff currently living in tools/perf/util/.
--
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