Re: Proposed relayfs changes in Systemtap

[Tom Zanussi <zanussi at us dot ibm dot com>]

Martin Hunt writes:
 > 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. 
 > 

Changing it to handle binary output transparently sounds like a good
goal.  Do these changes mandate that all users of the -b option write
their own output code in C (I assume 'output code' means
post-processing code)?  Would there be some interface with stpd?

 > 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.
 > 

I'm not sure I understand this part - can you expand on it a little?

Thanks,

Tom