[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ah, this is the right thing

From: Marcus Brinkmann
Subject: Re: ah, this is the right thing
Date: Thu, 22 Apr 2004 20:55:46 +0200
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At 22 Apr 2004 10:06:05 -0700,
thomas wrote:
> A magic console is a necessary thing to tolerate.  It's a way for
> programs to write on "the console" when they are the only beast in the
> world.  Right now they use the Mach "console" device.  That's a bug.
> That device will vanish like the wind when we strip away the Mach
> terminal code once and for all.

It's only a bug if you think of the Mach console as anything else but
the magic console itself.  In other words, if you remove the Mach
console, then you have to put something in there to take its place.
You can call it something different, like a "boot logging device", but
it needs to be something, and of course it doesn't even need to be in
Mach, although whatever it is must be integrated with other device
drivers to sort out the problems of concurrent access (directly or

So, let's try to formulate the questions you want to discuss, rather
those you don't want to discuss right now:

Let's call the entity that root servers are using for diagnostic
output at boot and crash time a "logging port".  Then in my
understanding this logging port should be created very early and
propagated to other initial servers.  In my opinion, this can very
well be in the form of a file descriptor for "stdout", although I
don't really care.  We could just as well make it more abstract,
forbid such servers from using stdin/stdout/stderr at all and use a
more abstract logging interface, something that is on the todo list
anyway.  printf is just one such logging interface, it's easy enough
to replace it with something else.

Now, in your second mail you wrote that init opens the "real" console
and gives back a port to it to the initial servers.  This would mean
that those servers replace their logging port with something else, or
that they cease to use the logging port and start to use a proper
console as stdout.  That this is the right thing to do is not at all
obvious to me.  It raises questions about what this "real" console is,
and if it has all the right properties.

What I think would be the right thing is to leave the logging port in
place, and use it for the whole life time of the servers.  Then the
logging port, or rather whatever implements its service, can do the
right thing from outputting on the screen to forwarding it to syslog
if polled for it.  init should be concerned about opening a real
console, but that console would only be used for console purposes of
init and its children.

In other words, I'd vote for a dedicated logging service, that is
started by or even before the root filesystem and other initial
servers.  The real work is then in the implementation of this logging

This would mean however that by default you wouldn't see messages on
the screen after init started and took over the hardware (assuming
that we use a shared single screen here, rather than a dedicated
logging hardware or serial line).  This is solvable, but not easily.
For example, if the machine then goes into a warmstart after a
failure, the log buffer could still be found in memory and read out
for diagnostic purposes, or a trace of the log buffer could be kept on
disk in a few dedicated blocks.  All of these are questions you want
to exclude, but which are crucial if you want to ensure that no
messages are lost while not having a dedicated logging hardware -
which is the only hard part about the whole design.

> Right now, we are doing a horrible thing.  We open the Mach device
> named "console" (a feature we are planning to remove from Mach
> anyway); we are casual and careless about where that port is passed
> around, including storing it in wildly inappropriate places, like file
> descriptor tables; init never bothers to open /dev/console for the
> users the way BSD does (and it's a mistake that Linux does not); we
> don't capture anything written on it for logging; etc.

It's clear that the current situation is not correct in many ways.
What is not clear is what should replace it.

I don't know what init in BSD does in terms of open /dev/console, can
you elaborate on that?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]