This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Implementing a generic binary trace interface.


Jose R. Santos wrote:
> This implementation is more generic and its available now.  While this
> is suitable for our current trace work, I still agree with Tom that this
> approach may not be as flexible for gathering other data types.  While
> having fixed data types make it easy to decode the binary trace, there
> may be situations were we may want to grab data that may not fit on
> either a size long arg or the 128 arg limit.

Thanks, and I think those situations would be rare case. Even if you
would like to transport some data structures totally, you can do it
over gBTI with a type signature by using custom tapsets.
However, in my opinion, interpretation of type information should be
left to each user. Because there are so many types and structures that
SystemTap can not handle all of them.

>  Also, while possible to
> write a function call with 128 args, this would look really ugly and
> seems error prone.  Having a basic struct data type on SystemTap would
> solve some of these issues.

I agree with the requirement of some special interface to transport
such a large data. One of simpler ways, I think, is to allow the
script functions to take long arrays as its arguments. Thus, we can
transport whole the array to user space as like below;

function array_log ( map:long[] ) %{
	struct map_node *node = _stp_map_start(THIS->map);
	// reserve region and write header
	int64_t * ptr = _stp_binary_reserve(THIS->map->num);
	while (node) {
		*(ptr++) = _stp_get_int64(node);
		node = _stp_map_iter(THIS->map, node);
	}
%}

This function does not consume the stack so much.

>> 2. stpd enhancement
>> We should enhance stpd daemon to handle both ascii packet and binary
>> packet
>> correctly. But it is not so difficalt.
>>
> I claim complete ignorance on how the stpd daemon works.  Can you
> elaborate on what the problem and possible enhancements are?  Does this
> still require your prohibit merging patch?

Yes, it is required, because of the reason below.
With relayfs, stpd daemon writes per-cpu data into per-cpu files. And
it sorts the entries of those files and merges to one file (or to
stdout) just before terminating. Currently, stpd's merging routine
can't handle binary packets. It will treat it as a 0 length string
and can't find the entries after a binary packet. So, you should
prohibit stpd merging files.

I think the solution is to improve stpd to merge binary packet and
ascii packet. I also developed external merging program. Its display
format of binary data should be discussed.

>> 3. wrapping functions
>> I also think we can define the various interfaces for example LKST, LKET,
>> or more generic binary_log() interface over the gBTI runtime.
>>
> This I like.  I would use this if it were available now on SystemTap.
>
>> What would you think about the gBTI?
>>
> Its a good solution and seems like we could port our trace to use this
> mechanism easily (which we would had to do anyway if we implemented our
> own BTI).  This could later be enhance with what Tom is proposing.  I
> would like to see this or an equivalent functionality as part of
> SystemTap though.  Since you move the functionality to a tapset, are you
> looking at maintaining this as part of LKST or do you have plans to get
> this into SystemTap itself?

Yes, I would like to merge this feature to SystemTap as a runtime.
The patch is under been developing.

>> I have already a concrete implementation of gBTI(for relayfs). I
>> developed
>> it as a tapset script including runtime part.
>> I attach two files to this mail.
>>
>> - gbti.stp:      gBTI core runtime (_stp_binary_write())
>> - lkst_gbti.stp: LKST compatible wrapping function of gBTI
>>
>> Please review it.
>>
>> Best regards,
>>
>>
> I've done a visual inspection and don't see any mayor issues with it.  I
> will play with it a bit and see how it goes.
>
> What is the purpose of having gbti_init()?

This is dummy function to implement _stp_binary_write() as a independent
tapset script (gbti.stp). Systemtap translator merges only the tapset
scripts which include some symbols used by the user script. Thus,
without calling gbti_init() from your script, the translator doesn't
merge gbti.stp and fails to build.

When gBTI is merged with runtime, gbti_init() is not required.

>
> Thanks
>
> -JRS
>

Best regards,

-- 
Masami HIRAMATSU
2nd Research Dept.
Hitachi, Ltd., Systems Development Laboratory
E-mail: hiramatu@sdl.hitachi.co.jp


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]