This is the mail archive of the systemtap@sources.redhat.com 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: Some notes on translation


On Fri, 2005-02-25 at 10:13 -0600, Tom Zanussi wrote:

> 
> OK, I certainly don't want to duplicate anything you were working on
> or were planning to work on.  Is there anything in what I've outlined
> that isn't already being covered by you or Frank or Will (or someone
> else on the list)?  If not, that's fine - I can easily find something
> else to work on...

The netlink API.  We will need that soon. I could also come up with a
list of additional runtime functions that I know will be needed but are
not implemented.  For example, stack dumps. 


>  > For output, I was planning on eventually supporting 3 different methods.
>  > One would be like you describe above; print using netlink. That would be
>  > the default. Another method (which Frank proposed) would use a /proc
>  > interface to allow polling of statistics.  And there would be some way
>  > to use netlink to dump high-bandwidth data to a file to be processed
>  > later.  I haven't thought much about that yet.  
> 
> I was thinking that the netlink API I proposed in the parent post
> should be able to cater to all of systemtap's needs - what happens to
> the data once it gets to userspace is up to the application (print to
> stdout, save to file, etc...).  The actual API and protocol need more
> thought, but the design goal would be to have a simple API that hides
> the details of the underlying implementation as well as modalities for
> at least the user side e.g. packet vs high-bandwitch vs /proc.  I'm
> not sure why we'd want to use /proc in place of netlink in any case -
> also I thought putting new stuff in /proc was discouraged anyway.

I don't know if it is discouraged.  I just see a potential need to poll
for data, rather than having it logged, and we had this proc code... You
are right that you could implement the same functionality over netlink,
which would be better.

We need both an underlying API, which would be part of the runtime, as
well as a userspace API.  There are also language concerns.  How do the
systemtap programs indicate where output goes and how it is formatted?

Martin



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