Changes to systemtap transport

[Martin Hunt <hunt at redhat dot com>]

I'm about to check in my rewrite of the systemtap transport.  The will
be mostly invisible to users, with one proposed exception.

The bulkmode (relayfs) options seemed overly complex and I have
simplified them. If you are writing apps which use it, I would like your
opinion.  

In the old system, "stap -b" would transfer data percpu, then when
finished merge the output into a single stream.  Anyone actually using
this? It seems useless especially in the new transport where stream mode
is as fast as bulk mode (probably except on NUMA systems).  

"stap -bM" would create percpu files "stpd_cpuN" Those files are in no
particular format and it is entirely up to the application (tapset?)
writer to put in timestamps, sequence numbers, etc. 

I am eliminating the merge function and the "-M" option, because "-b"
means percpu files. Also, "stap -b -o foo" will now work and save percpu
data in "foo_N" (where N = cpu number).

Now the real question. I think it would be best to have some basic
format that percpu data is stored in.  I propose having the transport
automatically put the following header on all data:

struct _stp_trace {
        uint32_t sequence;      /* event number */
        uint32_t pdu_len;       /* length of data after this trace */
};

This allows us to write standard utilities to sequence and extract data
from all percpu files.  I realize this will require modification to
applications which some of you have written to parse percpu files.
However I also think it makes it much easier to use for simple
applications because the system generates the sequence numbers and
lengths automatically.

Thoughts?

Martin