Re: Help with netlink needed

[Martin Hunt <hunt at redhat dot com>]

On Tue, 2005-03-29 at 14:05 -0500, Frank Ch. Eigler wrote:
> > 1. High-speed transfer of large amounts of collected data.  [...]
> 
> It would be helpful if you outlined end-to-end usage scenarios for
> such a data path.  Are you only talking about a script-level function
> call to replace printk()?  
No. More than that.

> Are you talking about asynchronous
> global-variable snapshots as per the old /proc code?  
I wasn't considering that as a primary feature.  It should be something
we could later support. I think we should be able to support custom data
streams defined by the probe.

> Do you imagine
> that result dumps would generally come from explicitly scripted trace
> calls during systemtap probe shutdown?

Explicitly scripted by the translator, not the systemtap probe code.

> > 2. A separate channel for immediate messages.  Used to signal error
> > conditions, print warnings, etc.  Anything that is not normal trace
> > output.
> 
> If such "health" status data was routinely inserted into the normal
> data stream, would a second such stream be necessary?
Having non-trace data in the trace buffer would make it more difficult
to read. Also, the point of having those status messages in a separate
channel would be so that they would be received, displayed, and acted on
immediately.  For example, the user-space daemon would need to recognize
fatal errors and optionally unload the module.

I'm asking for suggestions and help here. Before I did the research and
wrote up a proposal, I thought I'd ask for input.

But since you asked what I imagine...  Right now I'm thinking that
probes can call a printk-like function to write anything they want to
the "trace buffer"  (or whatever you want to call it).  When the buffer
fills or optionally a timer expires, that buffer is sent to the user-
space daemon. On module unload, variables are dumped to the trace buffer
(if the probe code requests it), which is then sent before the module
exits.

For extraordinary events (errors or warnings), there is a separate
command to send data directly to the user-space daemon.  

We may also want to support custom channels.  The probes can define a
new channel and instruct the daemon to save data on that channel to a
file or start up a program and forward the data stream to and from it.
This would allow your variable snapshots, as well as custom interfaces
for monitoring kernel internals.

Martin