Neal H Walfield wrote: > > Can you justify why this is better than syslog?
It is not inherently better than syslogd. It does, however, serve a slightly different class of process. I am not opposed in principle to adapting syslog to handle Hurd/Mach ports as opposed to Unix domain sockets or UDP sockets. The current implementations of syslogd I have been exposed to assume that the caller is sending information out on Unix sockets, UDP sockets which in my opionion are not the appropriate vessels for logging Hurd events. This is particularly true if the socket translator is to send messages. Using syslog as the basis for an implementation is probably a good idea, but in its present state, I don't think it is usable in general for hurd translators. The second point is that many of the hurd translators do not use syslog (perhaps out of concern for the issues I raise above). In fact, the only ones in the source base I could see were: daemons/getty.c, daemons/lmail.c, trans/pump.c ufs-utils/newfs.c Most of these are not real translators at all, but ordinary processes. On the other hand, many translators call 'error()' which according to glibc source does an 'fprintf(stderr' and I assert that logging may be more appropriate in some cases than a console message. In some cases, a simple 'errno' return value suffices which may or may not give an indication of what REALLY happened (as in the 'auth' example I pointed out earlier). Just my opinion. Jonathan S. Arney Software Engineer [EMAIL PROTECTED] ------------------------------------------------------------------------ _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd