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:	Fri, 10 Oct 2014 17:41:58 -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: [PATCH 1/1] rasd: Use perf_evlist__open() instead of open coded

Em Fri, Oct 10, 2014 at 10:28:54PM +0200, Borislav Petkov escreveu:
> On Fri, Oct 10, 2014 at 05:07:08PM -0300, Arnaldo Carvalho de Melo wrote:
> > I'll try  lding rasd.c with it and checking if it works.

> > Never having tried this, what are the requisites to test it? Some
> > specific hardware and a kernel with the right tracepoint? I guess some
> > recent 3.17-rc kernel is all that I need?

> Well, you'd need the part of Jean's patches which adds the event to evlist:
 
> https://lkml.kernel.org/r/1412933690-25576-1-git-send-email-jean.pihet@linaro.org
 
> AFAICT, you could apply patches 1-5 and replace 6 with yours. Now,
> rasd.cfg has the mce:mce_record tracepoint which rasd opens but you
> probably want to put a tracepoint which is much easier to exercise,
> maybe some syscall or whatever.

Right, stoopid me, no need for some specific tracepoint, just to see
that whatever tp it is, it will show up in "rasd"'s event loop. Ok, I'll
try that later.

Next stuff I probably will do is to move the bare minimum used by rasd
to tools/lib/api/perf/, i.e. there will be:

tools/lib/api/perf/evsel.c
tools/perf/util/evsel.c

Both will share the perf_evsel__ namespace (which I thought at some
point to make just: evsel__<METHOD_NAME>, wdyt?).

That way we just make public the bare minimum that already proved to be
useful outside tools/perf/ and over time we move stuff from
tools/perf/util/evsel.c (and from other tools in or out perf's repo)
into the lib.
 
> I think that should do it but we won't know until we've tried it.
> 
> HTH and thanks a lot for doing this!

Np, had to be done at some point :)

- Arnaldo
 
> -- 
> Regards/Gruss,
>     Boris.
> 
> Sent from a fat crate under my desk. Formatting is fine.
> --
--
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