Date: Sat, 27 May 2006 23:45:36 -0700 From: Lyndon Nerenberg <lyndon@orthanc.ca> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: arch@freebsd.org Subject: Re: A sort of plan for consoles in FreeBSD Message-ID: <10D0C601-EF31-40BA-9438-12F2C6D23A72@orthanc.ca> In-Reply-To: <20060528062623.GO744@turion.vk2pj.dyndns.org> References: <16029.1148764704@critter.freebsd.dk> <67EC575F-CEE3-43DF-A811-18930687DABD@orthanc.ca> <20060528062623.GO744@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 27, 2006, at 11:26 PM, Peter Jeremy wrote: > FreeBSD has had a message buffer as long as I can remember. Look in > <sys/msgbuf.h> for the API and kern.msgbuf for the content. I can't > find any man pages on it. I remember looking at this before a couple of times, but it seemed (I'm a bit fuzzy on the details now -- it's been a while) that the interface wasn't stable (or even documented, as you mentioned). If a documented API was nailed down, that would be great. But I would really like to see the read semantics of /dev/console made as I described, so that multiple readers could watch what was going on (e.g. multiple procs filtering the output and acting accordingly). This makes it much easier to write system monitors (ala swatch, doing the equivalent of 'tail -f') without having to do all kinds of ioctl goo against special /dev files. Being able to adjust the buffer size at runtime (via sysctl) would be a bonus. For example, when we get load storms on our web servers, it would be very helpful to be able to crank up the size of the buffer and turn up logging to try to catch something in the debug stream to explain what's going on. But I wouldn't want to run with a (say) 200MB console buffer in normal production. Dynamic sizing is perhaps just wishful thinking though -- we can certainly live without it. --lyndon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?10D0C601-EF31-40BA-9438-12F2C6D23A72>