Re: Hurd logging. (was zalloc panic)

[Jon Arney]

> 
> If sending something over a socket causes the socket server to log a
> message, then you have a serious problem anyway.
> 
> The same problem exists in a more minimal model: If writing something to a
> file causes the filesystem server to log a message, then you are in big
> trouble.

I agree, however, in the general case, I can see no really good way
around
this problem.  The minimal model merely reduces the chances that
'unclean'
or 'dangerous' paths are taken.  I also agree that logging should be
used
only for exception and unusual cases for obvious reasons not the least
of which is that one wants to prevent log events from causing more log
events.

> You'll have to make sure those pathes are clean.

Or that the likelihood of following an unclean path is vanishingly 
small.  There is nothing, for example, that says that the log events
must be posted synchronously.  I is possible to use ring buffers
and other mechanisms similar to Linux's klog/printk to reduce the
likelihood of causing problems.  

To take an example look at Linux's kernel logging.  Obviously a
'printk' inside a file 'write' function is dangerous even in Linux.
However, the mechanism, while flawed in the general case is still
useful in a wide variety of special cases. I hate to keep picking
on Linux for my examples, but it is a useful and instructive O/S.
I'd hate to throw the baby out with the bathwater in terms of
design approach.

> I disagree with our
> earlier analysis that for example EINVAL from the auth server is unhelpful,

Yes, perhaps this was an ill-conceived example.

> BTW, just as your information, stdout and stderr can be captured either by
> making the translator active:

Thank you for the tip.  This has already been helpful.

Thanks,


Jonathan S. Arney
Software Engineer
jarney1@cox.net
------------------------------------------------------------------------