[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

take a step back

From: Thomas Bushnell, BSG
Subject: take a step back
Date: 22 Apr 2004 15:19:46 -0700
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

When a system program--an ordinary system program--wants to do
some generic output, it normally uses syslog.

Under the hood, that means it opens a local domain socket to send
messages to the syslogd daemon.  syslogd sends those messages to a
variety of places: terminals, log files, etc.  It gets access to those
places with the open system call.

Programs often also use the LOG_CONS option.  If you use LOG_CONS, and
you can't contact syslogd for some reason, then the syslog call
instead writes them on the console.  It does this using
open("/dev/console") and write.

We are moving to a world in which /dev/console is implemented by a
more sophisticated program, which is a good thing.

Programs in general, especially when they first start, might also
write messages on stdout and stderr.

What I am saying is that:

1) Hurd servers should work exactly the same way independent of which
   server they are or when they get started, and
2) Every program except those started as passive translators should
   get a plausible file descriptor for 0, 1, and 2; which is
   conventionally whatever you get if you open "/dev/console", and
3) Because some servers are already running before syslogd and
   /dev/console are working, they need a way to print messages before
   the full blown system is operational.  I have referred to this way
   as "magic".  I'm not so concerned with how the magic works,
   provided we switch away from it cleanly once the system is
4) Messages printed through magic should eventually get directed to
   syslog so that they all get appropriate logged.
5) Magic should only be used for the brief period before syslogd and
   /dev/console are operational.

And, because it's come up,

6) When the system is crashing, magic may again become necessary, and
   in addition it would be nice to capture messages across reboots the
   way BSD does.

Now, two proposals:

A) Implement the magic inside the bootstrap filesystem, and it passes
a stdin/stdout/stderr file descriptor to itself which the rest of the
system can use as its magic.

B) Once the system is sufficiently running, /dev/console gets opened,
and the result is passed to the programs that got the magic from the
bootstrap filesystem, and they replace this as their
stdin/stdout/stderr.  At the same time, they begin using the syslog
for their messages.  All of my previous mail was directed to specific
proposals for this handoff.

And hey, the task of logging the magic can be done by the bootstrap
filesystem, since it has everything that was written on it anyway,
since it was the server.  It has to be sure to get things logged in
the right order: first the kernel's bootstrap output, and then the
magic, before anybody else starts logging things.

And, good golly, we can put all the magic in a library that the
bootstrap filesystem uses, and get terminal handling and fonts out of
the kernel if possible.  (Though alas, some may still be necessary for
the kernel's own boot messages.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]