Re: [RFC PATCH v4 10/29] bpf tools: Collect map definitions from 'maps' section

[Arnaldo Carvalho de Melo]

Em Mon, Jun 01, 2015 at 03:03:11PM +0900, Namhyung Kim escreveu:
> On Mon, Jun 01, 2015 at 01:19:16PM +0800, Wangnan (F) wrote:
> > On 2015/6/1 10:12, Namhyung Kim wrote:
> > >On Thu, May 28, 2015 at 08:35:19PM -0700, Alexei Starovoitov wrote:
> > >>On Thu, May 28, 2015 at 03:14:44PM +0800, Wangnan (F) wrote:
> > >>>On 2015/5/28 14:09, Alexei Starovoitov wrote:
> > >>As far as 'bpf_store_value' goes... I was thinking to expose perf ring_buffer
> > >>to bpf programs, so that program can stream any data to perf that receives
> > >>it via mmap. Then you don't need this '$outdata' hack.
> > >Then we need to define and pass the format of such data so that perf
> > >tools can read and process the data.  IIRC Masami suggested to have an
> > >additional user event type for inserting/injecting non-perf events -
> > >like PERF_RECORD_USER_DEFINED_TYPE?  And its contents is something

That would behave mostly like PERF_TYPE_TRACEPOINT but would look for
event /format definitions in another place? Perhaps one that is in a per
buildid location, i.e. each library has its own place to store such
field definitions, and by tying it to a particular version, it could
change it as it see fit?

> > >similar to tracepoint event format file so that we can reuse existing
> > >code to parse the event definition.

> > Is it possible to expose such format through
> > /sys/kernel/debug/tracing/events/*/*/format
> > so we can avoid extra work on perf side and make it accessable by both perf
> > and ftrace?

> No, I mean export such format through an event in perf.data file.  It
> still needs extra work on perf-tools side.  But by using user-defined
> event types, there should be no kernel-side work.
> 
> Above is just a suggestion how to deal with external data/events in
> perf.  But I'm seeing many people want such feature so we need a way
> to handle it anyway. ;-)

Right, having a way to map from a { attr.type = PERF_TYPE_USER_DEFINED,
attr.config = N }, to a description of the fields, like what we have now
for tracepoints, kprobes and uprobes, seems the way to reuse most of the
existing infrastructure.

We then collect just the /format files referenced in the perf.data file
and all seems to be in place, no?

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/