From mboxrd@z Thu Jan 1 00:00:00 1970 From: William Josephson To: 9fans@cse.psu.edu Subject: Re: [9fans] kprint Message-ID: <20011001101620.A7537@honk.eecs.harvard.edu> References: <20011001135702.B82B519B02@mail.cse.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011001135702.B82B519B02@mail.cse.psu.edu>; from rog@vitanuova.com on Mon, Oct 01, 2001 at 03:09:12PM +0100 Date: Mon, 1 Oct 2001 10:16:20 -0400 Topicbox-Message-UUID: f926fcb6-eac9-11e9-9e20-41e7f4b1d025 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