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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141006191227.GD14113@kernel.org>
Date:	Mon, 6 Oct 2014 16:12:27 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Jean Pihet <jean.pihet@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Fu Wei <fu.wei@...aro.org>, Robert Richter <rric@...nel.org>,
	Jiri Olsa <jolsa@...hat.com>, David Ahern <dsahern@...il.com>,
	Ingo Molnar <mingo@...nel.org>
Subject: Re: perf & rasd integration plan

Em Mon, Oct 06, 2014 at 05:16:06PM +0200, Borislav Petkov escreveu:
> On Mon, Oct 06, 2014 at 12:07:41PM -0300, Arnaldo Carvalho de Melo wrote:
> > So, why have you commented out the perf_missing_features fallbacks? Are
> > they getting in the way somehow, what can we do upstream, i.e. in
> > tools/perf/util/ so that it gets closer to what you want to have?
> > 
> > Ditto for all the other ifdef'ed code, can you elaborate on why each is
> > needed? That will help in moving what is used by rasd from
> > tools/perf/util/ to tools/perf/lib/ so that we can eliminate the
> > duplicity.
> 
> Oh, the reason is very simple: so that it builds. We don't need those
> facilities yet. We will enable them when needed but we wanted to
> concentrate on rasd first and later clean up stuff as we go.

Right, and it is being a great exercise, thanks for the patience so far
;-)

Looking at those ifdefs we see things that are specific to tools/perf/,
like perf_evsel having a struct hists embedded... I.e. that is of no
interest whatsoever (so far) to rasd, and in turn pulls other object
files.

So I think that right now we need to look at those ifdefs and go on
making what is in tools/perf/util/ stop using it somehow, so that what
then gets moved to tools/lib/api/perf/ (I guess this is where it should
be, opinions?) have that sorted out.

I.e. what goes to tools/lib/api/perf/ is what is common to the needs of
tools/perf/ and rasd (wherever it may roam).

Perhaps something like I did for sock/inet_sock/inet_connection_sock
ages ago... I.e. the tools that want a hists will have a 

struct hists_evsel {
	struct perf_evsel evsel;
	struct hists	  hists;
};

etc.

Experimenting with that, as it is the only thing ifdefed out in rasd's
copy of evsel.h...

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ