Re: [RFC 2/2] perf: Marker software event and ioctl

[Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>]

On Fri, 2014-09-12 at 17:19 +0100, Arnaldo Carvalho de Melo wrote:
> Em Fri, Sep 12, 2014 at 02:58:55PM +0100, Pawel Moll escreveu:
> > On Fri, 2014-09-12 at 14:49 +0100, Arnaldo Carvalho de Melo wrote:
> > > Perhaps both? I.e. an u64 followed from a string, if the u64 is zero,
> > > then there is a string right after it?
>  
> > How would this look like in userspace? Something like this?
>  
> > 8<----
> > struct perf_event_marker {
> > 	uint64_t value;
> > 	char *string;
> > } arg;
>  
> > arg.value = 0x1234;
>  
> > /* or */
>  
> > arg.value = 0;
> > arg.string = "abcd";
>  
> > ioctl(fd, PERF_EVENT_IOC_MARKER, &arg)
> > 8<----
>  
> > If so, maybe it would simpler just to go for classic size/data
> > structure?
>  
> > 8<-----
> > struct perf_event_marker {
> > 	uint32_t size;
> > 	void *data;
> > }
> > 8<-----
>  
> > This would directly map into struct perf_raw_record...
> 
> I can see the usefulness of having it all, i.e. if we do just:
> 
> perf trace --pid `pidof some-tool-in-debug-mode-using-this-interface`

Hm. I haven't thought about a situation when 3rd party wants to inject
something into "my" data stream... I guess it could be implemented (a
"pid" member of the struct perf_event_marker with default 0 meaning
"myself"?), but will definitely complicate the patch. Should I have a
look at it now or maybe leave it till we get a general agreement about
the marker ioctl existence?

> Then 'perf trace' doesn't know about any binary format a tool may have,
> getting strings there (hey, LD_PRELOADing some logging library to hook
> into this comes to mind) and having it merged with other events
> (syscalls, pagefaults, etc) looks useful.

But do you still mean a "magic" u64 before the rest? Injecting a string
would just mean:

	marker.size = strlen(s) + 1;
	marker.data = s;

> As well as some specialized version of 'perf trace' that knows about
> some binary protocol that would get app specific stats or lock status,
> etc, perhaps even plugins for 'perf trace' that would be selected by
> that first u64? Also seems useful.
> 	  
> I.e. having a way to provide just strings and another that would allow
> passing perf_raw_record.

Sounds interesting. But then maybe this stuff shouldn't go into "raw"
then? It could be something like this in the sample:

	{ u64 type; /* 0 means zero-terminated string in data */
	  u32 size;
	  char data[size]; } && PERF_SAMPLE_MARKER

Pawel