At Tue, 30 Jan 2007 15:41:05 -0800, Thomas Bushnell BSG wrote: > I see no reason why we should care about emulating klog. > > Hurd translators can, in general, perfectly well simply write directly > to the regular /dev/log socket in the regular way. Heck, even the > filesystem and pflocal translators can do so, since they are properly > multi-threaded. > > The only issue that needs to be addressed is a bootstrapping time one > here.
If we don't care about compatibility, then my wish list for a logging facility includes parent imposed labels which are prefixed (the entire derivation chain) before output thereby creating a chain of responsibility, and differentiating between informational ouput (stdout) and errors (stderr). For the former, this means that when syslog is started, a capability is handed to the starter. The only way to get a capability to syslog is via this capability. (Or, syslog sits in the file system and those who open it get a syslog whose prefix is initialized with their user name.) We then introduce an RPC to create a new logging capability from this one, syslog_derive (syslog_t syslog, const char *prefix). This can be applied to any derived syslog capability, as well. syslog capabilities also implement the I/O interface so they can be used as file descriptors. So, for example, the root file system has the initial capability to syslog. When some translator of mine is started, it might create a derived syslog capability with the prefix: /path/to/trans:trans:neal. If my translator derives a syslog capability from this one, it extends the prefix. This makes it clear exactly who is responsible for have started a program instance. Neal _______________________________________________ Bug-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-hurd
