Thomas Bushnell BSG wrote:
I cannot see any reason why, once the system is up and running, even
proc cannot simply syslog just like anything else, provided it does not
hold internal locks as it does so (and this should be true for *every*
call to syslog anyhow, in whatever program).
I can see h
typo corrections... @!#$&*!!
Thomas Bushnell BSG wrote:
I cannot see any reason why, once the system is up and running, even
proc cannot simply syslog just like anything else, provided it does not
hold internal locks as it does so (and this should be true for *every*
call to syslog anyhow, in wh
On Wed, 2007-01-31 at 19:13 +0200, Constantine Kousoulos wrote:
> typo corrections... @!#$&*!!
>
> Thomas Bushnell BSG wrote:
> > I cannot see any reason why, once the system is up and running, even
> > proc cannot simply syslog just like anything else, provided it does not
> > hold internal locks
Thomas Bushnell BSG wrote:
We generally tend to dislike the use of asynchronous messages. They are
great for Mach, but we would like to avoid the need to use them in
general.
Keeping things always as RPCs makes the system much more likely to be
portable in the future to other kernels.
It's n
On Thu, 2007-02-01 at 00:22 +0200, Constantine Kousoulos wrote:
>
> It's nice to know the direction the implementation is headed. I
> would be grateful if you could supply links that further document
> the above mentioned statement. To be honest, i had the exactly
> opposite idea since it has b
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 transla
