linux-kernel - Re: [RFC] perf-cache command interface design

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]
Message-ID: <20141107143804.GA2137@redhat.com>
Date:	Fri, 7 Nov 2014 12:38:04 -0200
From:	Arnaldo Carvalho de Melo <acme@...hat.com>
To:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Cc:	Hemant Kumar <hemant@...ux.vnet.ibm.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Mark Wielaard <mjw@...hat.com>,
	David Ahern <dsahern@...il.com>, Jiri Olsa <jolsa@...hat.com>,
	Namhyung Kim <namhyung@...nel.org>,
	linux-kernel@...r.kernel.org, srikar@...ux.vnet.ibm.com,
	peterz@...radead.org, oleg@...hat.com,
	hegdevasant@...ux.vnet.ibm.com, mingo@...hat.com,
	systemtap@...rceware.org, aravinda@...ux.vnet.ibm.com,
	penberg@....fi, brendan.d.gregg@...il.com, acme@...nel.org,
	"yrl.pp-manager.tt@...achi.com" <yrl.pp-manager.tt@...achi.com>
Subject: Re: [RFC] perf-cache command interface design

Em Fri, Nov 07, 2014 at 05:21:08PM +0900, Masami Hiramatsu escreveu:
> Hello,
> 
> Here, I've tried to describe my idea of perf-cache subcommand interface.
> It is just a design review, not implemented yet :)
> Please give me your comments/ideas!
> 
> Command-line Synopsis
> =====================
> 
> Current "perf buildid-cache [options]" are directly mapped to
> "perf cache --buildid [options]".
> 
> And adding --sdt for managing SDT caches as below.

Can't we avoid having to specify the content? I.e. the tool can surely
be smart enough to figure that out, no?

We should, as much as possible, to make things more compact yet
unambiguous, IMHO.
 
>   Add or update SDT events in <FILES>
>     perf cache --sdt --add|--update <FILES>

Can automagically figure this out, so, it would become just:

	Add or update events in <FILES>

	  perf cache --add/--update <FILES>
 
>   Remove all SDT events for <FILES>
>     perf cache --sdt --remove <FILES>

Ditto.
 
>   List all SDT events
>     perf cache --sdt --list

That is ok, since the cache can hold different types of contents, but:

	perf cache --list

should show everything, with some marking showing the content type.
 
> And --probes for managing probe-caches as below.
> 
>   Add new probe-cache entries for kernel, <PATH> or <MOD>.
>     perf cache --probe [--exec <PATH>|--module <MOD>] --add <SPEC>

No need to specify --probe
 
>   Delete existing probe-cache entries for kernel, <PATH> or/and <BUILDID>.
>     perf cache --probe --del [<GROUP>:]<EVENT>[@<PATH>][#<BUILDID>]

Ditto
 
>   Or remove all entires for given FILES
>     perf cache --probe --remove <FILES>

Ok
 
>   List the probe caches(including SDT) for kernel, <PATH>, or/and <BUILDID>.
>     perf cache --probe --list [@<PATH>][#<BUILDID>]

Can figure out the kind by the initial character, so no need to specify
--probe
 
>   Query the probe definitions.
>     perf cache --probe --query [<GROUP>:]<EVENT>[@<PATH>][#<BUILDID>]

Ditto
 
> Note that --probes also can be used for managing SDT events, which has % prefix
> e.g.
>   Add all SDT events for <PATH>
>     perf cache --probe --exec <PATH> --add '%*:*'

See? --probe is smart enough to deal with SDT and probe caches, it can
disambiguate by looking at the first char.
 
>   Remove some SDT events for <PATH>
>     perf cache --probe --del '%some:events@<PATH>'

No need for --probe
 
>   Or remove all SDT events for <BUILDID>
>     perf cache --probe --del '%*:*#<BUILDID>'

Ditto
 
> 
> File Format
> ===========
> All the cache files are placed under ~/.debug/ by default.
> The paths of buildid cache of binary/symbols are not changed.
> 
> The SDT/probe caches are placed under the ~/.debug/.probes/path/to/bin/bu/ildid

Here I think we could group everything related to a /path/to/bin into:

~/.debug/path/to/bin/bu/ild/

With one file per content type:

~/.debug/path/to/bin/bu/ild/elf
~/.debug/path/to/bin/bu/ild/probe

That leaves room for us to add more file formats (CTF anyone? The Dtrace
one, Compact C Type Information, I mean).

So that if we wanted to pick everything related to a pathname we could
do:

tar cf gcc.debug.tar ~/.debug/usr/bin/gcc/

If we instead wanted to pick all files to a specific gcc build id, we
would do:

tar cf gcc.debug.tar ~/.debug/usr/bin/gcc/bu/ild/

> and that is linked to ~/.debug/.probes/.buildid/bu/ildid

Since this would break compatibility with the existing cache format, we
could as well allow collecting everything related to a build id, by
making the link be also in this fashion:

tar cf bu.ildid.tar ~/.debug/.build-id/bu/ildid/

Because we would have:

~/.debug/.build-id/bu/ildid/elf -> ~/.debug/usr/bin/gcc/bu/ild/elf
~/.debug/.build-id/bu/ildid/probe -> ~/.debug/usr/bin/gcc/bu/ild/probe

And also links to the files that have no pathnames:

~/.debug/.build-id/bu/ildid/vdso -> ~/.debug/[vdso]/bu/ild
~/.debug/.build-id/bu/ildid/kallsyms -> ~/.debug/[kernel.kallsyms]/bu/ild
~/.debug/.build-id/bu/ildid/kcore -> ~/.debug/[kcore]/bu/ild

> # To avoid conflict with files under /probes/*, I picked up .probes/.
> 
> This SDT/probe caches contain probe-definitions as following format.
> ----
> #buildid:BUILDID
> #path:PATH
> p:%PROVIDER/EVENT PATH:OFFSET [ARGS]
> p:PROBE/EVENT _text+OFFSET [ARGS]
> ----
> 
> Normal probes and SDT cache entries can be mixed in a cache file, we'll
> load all the entries and filter by % prefixes.

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