> > When I'm debugging something requiring detailed tracing, I don't want> to have to think about whether the tracing tool has the particular> behaviour, performance, data loss, and other such characteristics> needed for my immediate needs. It is easier to code up some little> ad hoc mechanism than it is to try to figure out whether some general> purpose mechanism is suitable and how to use the generic mechanism.

You can do lots of modes with relayfs already - no ping-pong buffer,n-buffer, lossy, not lossy etc etc.

I currently use it in 'flight-recorder' mode where new messages overwriteold ones.

It might be good to document different possible ways of using relayfs.

> If there are enough specific purposes for relayfs, fine. But beware> of over generalizing its potential usefulness. There is always the> risk of over designing it, adding additional flexibility and options> in an effort to gain customers, at the expense of making it less and> less obviously useful in a trivial way for any specific purpose.

It's currently pretty limited - but you can add more features on top of it,in a modular fashion. I tend not to use the complex stuff, but you can layerit if you want.

It'd be nice if we had some basic relaying infrastructure available that'dcover most needs successfully. Advanced users can do advanced things if theywant.