| 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
| ||
|
Message-ID: <545D9B7D.6070307@hitachi.com> Date: Sat, 08 Nov 2014 13:26:37 +0900 From: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com> To: Arnaldo Carvalho de Melo <acme@...hat.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 (2014/11/07 23:38), Arnaldo Carvalho de Melo wrote: > 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. Agreed. > >> 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> Ah, nice idea :-) > >> 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. Yeah, as I replied to Hemant, --sdt/--probe can be unified. > >> 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 OK. >> 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. OK, but --add already have FILES arguments (according to buildid-cache) So I'd like to move that pattern argument to --probe as I've described in previous reply to Hemant. > >> 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 Ah, OK, this is good for me too. :) > > That leaves room for us to add more file formats (CTF anyone? The Dtrace > one, Compact C Type Information, I mean). Perhaps. > 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/ OK. >> 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 OK, so let's make bu/ildid to a directory :) Thank you! -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu.pt@...achi.com -- 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