Help with netlink needed

[Frank Ch. Eigler]

Hi -

hunt wrote:
> [...]
> > > 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.

For whom?  Given that you already intend to put timestamp codes, and
potential message bracketing metadata in there, a user's eyes would
rarely gaze at this.

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

Can you explain why immediacy, in a sense such as "jumping the queue
of already enqueued healthy entries in the trace buffer", is
necessary?  After all, if the user-level daemon was already closely
monitoring one channel in some sense, it could do the same with both.


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

Yeah, maybe this would be interesting.  If implemented by using
distinct relayfs channels (whatever form they take at user level),
then my concern about a separate health channel is made moot.


- FChE
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20050406/248c0f1f/attachment.sig>