bash programming request [Bootscripts]

Bryan Kadzban bryan at kadzban.is-a-geek.net
Sat Jan 1 06:17:06 PST 2005


DJ Lucas wrote:
> as far as the kernel messages are concerned, would it be possible to
> redirect these to a buffer someplace? Effectively a fifo for our
> purposes (note not a real fifo)...this is over my head ATM, but it
> seems to me that we could capture them in some way and then replay
> them.  In rc, check our buffer and print after each of the scripts
> finish.

As far as I know, the redirection isn't possible.

They are not printed by *anything* in userspace.  They're printed to the
current console directly from the kernel when a message gets logged with
a severity above whatever threshold dmesg -n has set.

All kernel messages also go into a ring buffer, regardless of dmesg -n,
which means that we *could* check that buffer ourselves (from C, not
from bash).  But that would duplicate most of dmesg's functionality, and
how would we flag which messages we've already seen?  Where would we
store them?  The filesystem may not be writable yet, so it'd have to be
either a tmpfs/ramfs, or in memory directly (which means we'd need
another daemon).

Then, to check it, you'd almost need another thread responding to
signals from the bootscripts and printing new messages to that process'
stdout.  (I say another thread because I don't know how to do "thread
synchronization" between signal handlers and the main program loop, and
you'd definitely need synchronization for the buffer.)

It might be nice, but it would also be a lot of work duplicating so much
code (from dmesg, from printk, ...).

> As I mentioned before, for myself, I simply dispose of everything
> below priority 3 (info and below are sent nowhere) with the
> console-log script.

This is MUCH simpler.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-dev/attachments/20050101/c853e1d1/attachment.sig>


More information about the lfs-dev mailing list