Re: Changing log()

[Martin Hunt <hunt at redhat dot com>]

On Wed, 2006-04-12 at 17:00 -0400, Frank Ch. Eigler wrote:
> hunt wrote:
> 
> > [...]
> > Actually I was planning on tackling s similar issue soon. It is part of
> > a proposal to create "temporary buffers".  [...]
> > 
> > < create a buffer named tmp1 of size M>
> 
> How would this buffer creation work in practice?  Remember to what
> effort we go now to avoid any run-time memory allocation.

It would be preallocated.

> > buffer(tmp1) ; # all prints go to tmp1 now
> 
> Would this effect the current probe only?  If not, what about
> concurrency issues?
> 
> > < print a bunch of stuff> 
> 
> (presumably, using plain printf() or similar functions?
> 
> > buffer (stdout) ; # switch back to standard buffer
> > buffer_write (tmp1) ; # copy tmp1 to stdout
> 
> What if the "tmp1" buffer is larger than the available output space? 

An implementation detail. Obviously I haven't had the time to work out
all the details of the syntax. I have some ideas about implementation
and I will write them up with some proposed syntax at a later date.

> > I see these as a way to buffer lots of output without writing huge
> > log files. They would be circular and extremely fast because they
> > don't have userspace transport, disk IO, etc.
> 
> You realize that there is an inherent tension between being "huge" and
> "extremely fast"?  

Not in this case. What I mean is that instead of writing gigabytes of
tracing data that will mostly be ignored, with the temporary buffers you
can write the data to a 10M (for example) circular buffer then whenever
you want, write the last 10M of saved data to the output. Think of
something like the flight data recorder where a system might be busy
logging data to a temporary buffer for days before a problem. Then when
the problem happens, it dumps just a few megabytes to the output file.

> Some more quantitative analysis would be nice to see to justify this
> approach, such as a worked-out example with estimated probing
> rate/counts and enqueued trace data amounts.

I don't see how any specific analysis is required to justify this
feature.  Probably I just explained it too hastily. It seems simple
enough and useful.  Log data to a circular buffer so we can later see
the last N bytes of saved data. Exactly what I used to do with network
traces 15 years ago.