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]

Date:	Fri, 07 Nov 2014 16:21:34 +0530
From:	Hemant Kumar <hemant@...ux.vnet.ibm.com>
To:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Namhyung Kim <namhyung@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
CC:	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,
	"yrl.pp-manager.tt@...achi.com" <yrl.pp-manager.tt@...achi.com>
Subject: Re: [RFC] perf-cache command interface design


On 11/07/2014 01:51 PM, Masami Hiramatsu wrote:
> 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!

Thanks, I have some comments below.

> 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.
>
>   Add or update SDT events in <FILES>
>     perf cache --sdt --add|--update <FILES>
>   Remove all SDT events for <FILES>
>     perf cache --sdt --remove <FILES>
>
>   List all SDT events
>     perf cache --sdt --list
>
> 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>
>
>   Delete existing probe-cache entries for kernel, <PATH> or/and <BUILDID>.
>     perf cache --probe --del [<GROUP>:]<EVENT>[@<PATH>][#<BUILDID>]
>
>   Or remove all entires for given FILES
>     perf cache --probe --remove <FILES>
>
>   List the probe caches(including SDT) for kernel, <PATH>, or/and <BUILDID>.
>     perf cache --probe --list [@<PATH>][#<BUILDID>]
>
>   Query the probe definitions.
>     perf cache --probe --query [<GROUP>:]<EVENT>[@<PATH>][#<BUILDID>]
>
> 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 '%*:*'
>
>   Remove some SDT events for <PATH>
>     perf cache --probe --del '%some:events@<PATH>'
>
>   Or remove all SDT events for <BUILDID>
>     perf cache --probe --del '%*:*#<BUILDID>'

Looks nice to me :)

>
> 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
> and that is linked to ~/.debug/.probes/.buildid/bu/ildid
> # 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]

I think this format isn't accepted by the uprobe_events file (because of
the '%') if we want to cat and grep into uprobe_events file directly.
Although, in case of perf record, we can process it to remove '%' and
then write into uprobe_events file. And, '%' is required as a flag for
the SDT entries.
So, either we can modify the uprobe_events file to ignore '%' in the
event group name (with an additional patch in the SDT series) or we can
leave it to the user to write a script which can do some processing to
remove '%' and then echo it to uprobe_events file.
What would you think?

> 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.
>
>
> Thank you,
>

-- 
Thanks,
Hemant Kumar

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