This is the mail archive of the
mailing list for the systemtap project.
Re: Proposed relayfs changes in Systemtap
- From: Martin Hunt <hunt at redhat dot com>
- To: Tom Zanussi <zanussi at us dot ibm dot com>
- Cc: SystemTAP <systemtap at sources dot redhat dot com>
- Date: Fri, 08 Sep 2006 14:37:24 -0400
- Subject: Re: Proposed relayfs changes in Systemtap
- Organization: Red Hat Inc.
- References: <1157648096.2586.24.camel@dragon> <firstname.lastname@example.org>
On Fri, 2006-09-08 at 10:42 -0500, Tom Zanussi wrote:
> 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)?
It would work like today, merging automatically unless "-M" is used. The
only difference is that the merged output could contain binary.
To use binary today, you have to write your own embedded C functions to
put the data in the output buffers and modify stpd. With my proposal,
binary would just work, but of course you might want to write an
application to properly process the binary.
> Would there be some interface with stpd?
I don't see any need for one. But I'm open to suggestions.
> > 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?
We need to be able to handle precompiled modules, to run on systems with
no C compiler or just to save time when compiling and running the same
scripts over and over. Currently, the module knows if the output is
procfs or relayfs and tells stpd which it is using. We need to do the
same for relayfs merged output. This is because we want to allow people
to write any binary data they want to relayfs and then later process the
per-cpu files with their own application. But we also want the merged
output which is easier to use and test. That output must be sent to stpd
in some format that allows it to be processed. That format is just
sequence number, length, data, ... Stpd needs to know which to expect.