Re: ah, this is the right thing

[Thomas Bushnell, BSG]

Marcus Brinkmann <marcus.brinkmann@ruhr-uni-bochum.de> writes:

> 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.

I do think it's a mistake to have something like that there at all.
Maybe it *must* be.  But it's still a mistake to continue to use it
once the system has been booted.  

The *point* of calling it "magic" is to say that it is special, and
*not* the normal thing.  I have precious little interest in how the
magic thing works, but I *am* concerned that it only be used when it's
actually *necessary*.

Once the system is running, exec, or init, or the bootstrap filesystem
should log their messages just like every other system process does.
*That* is the important point.

> 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.

Right now, they are doing the *wrong* thing.

> 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
> service.

Fine.  That logging service is the "console" as I have already
described it.  All that I wrote continues to be relevant.

> 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.

It's trivially solvable.  Until the logging service starts, messages
go to the magic and to the logging service.  

Or we could do just what Unix kernel do: they print things and also
store them in a buffer.  Once syslog is running, the messages are
handed to syslog for logging, but unlike most messages, syslog doesn't
print these on the console; they are tagged for logging only.
Everything works.  Bing!

At crash time, for BSD, any unread syslog messages are copied to a
special memory buffer, and when the kernel boots, it looks at that
location in memory, saves the messages, and feeds them to syslog
(before the newly generated messages).  And bingo, panic requests and
everything else normally get logged! 

There is no reason we cannot make this work.

> 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?

It opens /dev/console, and puts that on fds 0, 1, and 2. 

Thomas