> > > 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.
If the memory was allocated specifically for that purpose, then released and
replaced with a smaller buffer, it might be a nice way to catch a large
number of boot messages.
> 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).
Hmmm. I've actually written logging code that just tests for
pre-initialization state and takes some substitute action in that case. In
the case you describe, that would be about all you could do; display on the
console and panic. You wouldn't normally expect this outcome early in
the bootup process; it wouldn't happen too terribly often. A debugging
variable to lilo might provide an alternate approach of suppressing the
panic to get you up and running after you noticed such a panic.
It can be helpful, in general, to have some sort of alternate case for
situations in which one attempts to log and logging is not initialized;
especially since in the case of kernel code it's pretty well given that not
all the code was written by the same person at the same time, hence it's
always possible someone will add code to do logging before logging is
actually available....
lilo