This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Proposed relayfs changes in Systemtap
- From: Martin Hunt <hunt at redhat dot com>
- To: SystemTAP <systemtap at sources dot redhat dot com>
- Date: Thu, 07 Sep 2006 12:54:56 -0400
- Subject: Proposed relayfs changes in Systemtap
- Organization: Red Hat Inc.
I would like to check in some changes to how relayfs is used in
systemtap. I already have almost all the code, it's just a matter of
cleaning it up a bit and getting it checked in.
Currently, the "merged" output is almost useless because it is slow and
cannot handle binary output. I expect almost all the users of relayfs
write their own output code in C. Merged output, however, is very useful
for testing and offers some improved performance.
I'd like to fix the merged output to handle binary output transparently.
So "probe.out" would have exactly the data sent to it, binary or ascii.
The next change would be adding
/** Reserves space in the output buffer for direct I/O.
*/
static void * _stp_reserve_bytes (int numbytes)
This would work for procfs or relayfs merged or not and would be
compatible with buffered output.
Then I could also add a binary print for both procfs and relayfs.
/** Write 64-bit args directly into the output stream.
* This function takes a variable number of 64-bit arguments
* and writes them directly into the output stream. Faster
* than doing the same in _stp_vsnprintf().
* @sa _stp_vsnprintf()
*/
static void _stp_print_binary (int num, ...)
Of course this would print only numbers and not add in any
application-specific headers. Is this useful or is everyone happier
just rolling their own?
There are some internal changes that won't be obvious to users. For
example, the "-M" option to stap needs to change the generated code and
that code should tell stpd that the output is in the standard format and
should to merged. That way we can load precompiled modules and get the
correct output.
Martin