Re: [9fans] kprint

Re: [9fans] kprint

[Russ Cox]

William is right on all counts.

I want to add:

	o storage: do you have a circular buffer, or just accept an
	ever-increasing buffer size ?

We use qnoblock(kprintoq, 1), which results in dropping
the tail of the log.  It's an 8k log, so if someone is reading
I don't expect any drops.

	o do you allow user processes to append messages themselves,
	possibly a convenient place to put daemon log messages?

As Rob's man page excerpt pointed out, if you write to
#c/cons on a bitmapped terminal and /dev/kprint is open,
the output only goes to kprint.  That seemed easier to explain
at the time.  So syslog(1, ...) gets sent to kprint if in use.

Russ

Re: [9fans] kprint

[William Josephson]

On Mon, Oct 01, 2001 at 03:09:12PM +0100, rog@vitanuova.com wrote:

The following only apply to my backport, but:

> some issues that i was wondering about:
> 	o storage: do you have a circular buffer, or just accept an
> 	ever-increasing buffer size ?

I just use a Queue with an 8K limit.  IIRC, that's what the new kernel
does, too.

> 	o blocking: does a process reading at the end of the file
> 	block until the next kernel print message arrives or does it
> 	look like a normal file which you have to poll (e.g.  tail -f)?

Currently, the process blocks -- I just open a rio window and type
'cat /dev/kprint' and put the window in scroll mode (or not).

> 	o do you allow user processes to append messages themselves,
> 	possibly a convenient place to put daemon log messages?

One could, I suppose.  I haven't thought about it, but it seems to me
that I'd want a more general logging facility that could write
messages to stable storage if I were doing that.  It might be better
to separate the two and have log messages and kernel prints go
somewhere else for logging.  At least as I use it, /dev/kprint is for
reading exceptional messages while I'm debugging so I don't hose rio.

> 	o multiplexing: do you allow several processes to access kprint
> 	simultaneously?

/dev/kprint is exclusive use.  This is how it is in the new kernel, too.
At least in my case, it makes the implementation easier and I don't think
the added complexity would yield all that much benefit given how I use it.

 -WJ

[9fans] kprint

[rog]

> A very pleasant addition which I just backported to 3rd Ed. this
> weekend.  Quite convenient.  Didn't realize it was Russ's idea, though.

it's a fairly natural thing to do, i think.  i've wanted to do something
similar in inferno for a while.  (^t^tp destroying the screen on a
bitsy is annoying).

some issues that i was wondering about:
	o storage: do you have a circular buffer, or just accept an
	ever-increasing buffer size ?

	o blocking: does a process reading at the end of the file
	block until the next kernel print message arrives or does it
	look like a normal file which you have to poll (e.g.  tail -f)?

	o do you allow user processes to append messages themselves,
	possibly a convenient place to put daemon log messages?

	o multiplexing: do you allow several processes to access kprint
	simultaneously?

  rog.

Re: [9fans] kprint

[suspect]

The original iteration of the "console" window, now the "log" window did
something along those lines. I never figured why it was changed to
what it is now, or whether those changes were not directly merged.
-



On Mon, 1 Oct 2001 rog@vitanuova.com wrote:
>
> it's a fairly natural thing to do, i think.  i've wanted to do something
> similar in inferno for a while.  (^t^tp destroying the screen on a
> bitsy is annoying).
>