This is the mail archive of the systemtap@sourceware.org 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: Changing log()


On Wed, 2006-04-12 at 11:39 -0700, Stone, Joshua I wrote:
> Martin Hunt wrote:
> > log() currently does a subset of what print() and printf() do. It is
> > not useful and should be either deprecated and removed or redefined.
> 
> log() is equivalent to libc's puts().  It may not be terribly useful,
> but I don't see the harm in keeping it around.

It's not really harmful, I'm just trying to keep the language simple,
without too much duplicated functionality. But maybe it is too late to
be making changes that break scripts.

> I understand the usage model, but why should this be a redefinition of
> log()?  Adding a new function, notify() or info() perhaps, would serve
> your need without breaking old scripts.

True.  I like info().

> This may also be the time to consider implementing equivalents to
> fputs() and fprintf().  This would allow you to explicitly route output
> to stderr, and we could also permit separate files for logging output.
> For example, it may be useful to separate text and binary output, or
> even have multiple binary output files.

Actually I was planning on tackling s similar issue soon. It is part of
a proposal to create "temporary buffers".  In brief, you can create
multiple output buffers, then switch between them. I haven't decided on
the syntax, but it would work something like this:

< create a buffer named tmp1 of size M>
buffer(tmp1) ; # all prints go to tmp1 now
< print a bunch of stuff>
buffer (stdout) ; # switch back to standard buffer
buffer_write (tmp1) ; # copy tmp1 to stdout

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 could put things in them and
then later decide if you want to copy any or all of them to the output.
For example, you could print all kinds of trace information to a temp
buffer, then when some specific problem happens, you have a trace of the
most recent things that happened up to that point. Then you would print
that temporary buffer. 

Now is it enough to simply redirect all output to a temporary buffer or
is there a realistic need to have multiple buffers and to be switching
between them? In that case, we would need something like fprintf().

What I am not going to propose is a way to write multiple files from
systemtap. I still think the output should be one file or, in the case
of relayfs, a single set of per-cpu files.  Anything else
overcomplicates things too much and can be handled with
post-processing. 

Martin








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