> Someone cares to syslogify the Hurd now? Oh yeah, I forgot to answer this part. The main issue here is making sure we use a highly robust way of getting the messages out without blocking, both early during boot-up or any time things get badly frotzed.
syslog (openlog) has LOG_PERROR and LOG_CONS to get messages out when syslogd is not running, and that suffices on Unix writing to the console never blocks undesireably unless the whole system is scrod. In the Hurd, it's a different story. During boot, the terminal server is not yet running at all. Also, At any time, a bad system problem could make attempts to write to or open /dev/console fail or (worse) block. The equivalent "safe thing" is writing to the Mach "console" device directly. Currently, the essential servers open the Mach "console" device directly and do their output to that (via a special stdio stream made with mach_open_devstream). The bootstrap filesystem (libdiskfs), init, and proc do this; auth doesn't, but in fact auth is so simple that it never has anything to print after initial startup. It is vital that these servers never risk blocking on any other server when writing their error messages. (They already depend on the kernel and the pagers backing their memory, i.e. the default pager and the bootstrap filesystem. Those are unavoidable.) Probably the right thing to do is put a new Hurd-specific implementation of syslog in libc. This can use Mach IPC directly with low-level options to ensure that it doesn't block badly trying to talk to syslogd, and it can implement LOG_CONS using the Mach console device directly when possible. Such a new implementation is unlikely to go into libc 2.1, it will have to wait for 2.2. An improved syslog would add robustness to every program using syslog and so is probably ultimately desireable regardless. But there is another notion that comes to mind for the essential servers. I am still ambivalent about this idea. The idea is to use the "kmsg" kernel device for the essential servers' messages as well as the kernel's. We add support for opening the "kmsg" device for writing, to allow user messages to be appended to the internal buffer the same way as kernel messages are. The essential servers can then use this device to write their error messages; because it is a kernel device that cannot block, they can use it as freely as they would the Mach console device. When and if klogd and syslogd run, they will suck up the messages from the essential servers along with the kernel messages. Since the kmsg device is a nonblocking device with a fixed-size internal buffer used as a ring, this is most like what happens on Unix (and Linux). It also has the same properties that you could conceivably arrange to retrieve a kmsg buffer from memory on warm reboot after a crash, and see the dying messages from both servers and kernel. I'm leaning away from this idea though. It just seems non-Hurdy.
