True. But that explains why messages that could be seen on the
scroll back weren't being written to the logs. They over flowed
the internal buffer, but not the memory associated with the
screen.
> > If you're generating more than 8k of data, perhaps you can
> > rearrange things to start up syslog sooner.
>
> Or the buffer could be extended. 8k isn't much, this might make a nice
> config option if it isn't already.
About the only time a buffer this large is useful is upon boot.
After boot, I doubt the buffer ever fills up if the sysklogd
stuff is running. A larger buffer just for catching all the boot
messages might not be the best solution.
This reminds me. There was once a page that had a bunch of
patches for improving kernel memory usage. It include such
things as kswap (before it became official), reducing the number
of supported options for floppy drives (ie, only using 1.44 and
720 for a 3.5, for example, not all the other esoteric ones), and
reducing said buffer to 1k.
For a stable system, mebbe not a bad idea. For a system with
modifications (ie, new hardware, new kernel, etc), perhaps upping
the buffer to be sure to catch everything isn't a bad thing.
Shame that buffer can't be kmalloced (It could be called by
kmalloc).
mrc
--
Mike Castle .-=NEXUS=-. Life is like a clock: You can work constantly
mcastle@cs.umr.edu and be right all the time, or not work at all
mcastle@umr.edu and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen