Re: ah, this is the right thing

[Marcus Brinkmann]

At 21 Apr 2004 22:36:57 -0700,
thomas wrote:
> Ok, this is the right thing to do.  It comes in two flavors, with a
> magical component.
> 
> The ideal flavor is this:
> 
>   * The bootstrap filesystem initially writes on the console through
>     magic.  Perhaps it passes the magic to init and exec.

I still have no clear picture of what the system console is in your
opinion.  In your first mail, you say that init must start the
console, because it may be "fancy" and require proc and auth.  But in
my opinion, it is a fundamental flaw to rely on a fancy console as the
system console.  The system console in my eyes is for example a
dedicated serial line, or a dumb terminal a la Mach's console, with
the one improvement that it doesn't interfere with other video card
using programs later on.

So, I think that the right thing is to use a dumb console as a system
console, which is magic in the way that it can change its behaviour
(ie, stop using the video card at some point, etc).

I realize that this picture is slightly different from what you have
in mind.  But keeping the system console separate from the user's
fancy consoles (which may very well be just XFree86, ie not a text
console at all), seems to make sense to me.

Now, this brings into question what this magic console should be and
how it should behave.  If it is a serial dedicated line, it will not
interfere with video card users, and this setup is indeed an easy one.
It gets harder if you want to share the system console resources with
other users, and this is currently on of the reason why you can not
use my console program on GNU Mach CVS Head (oskit-based).

However, as you deliberately excluded this question (how the magic
console should behave) from discussion, I don't need to answer it here
:)

In fact, I am still not yet done with my doubts about what the system
console really should be.  If it is shared by init etc and the root
filesystem for diagnostic output, then it is a mixed logging and login
console.  This is desired because you want to see the error messages
of course, while still being able to log into single user mode and so
on.  It causes a problem however if the filesystem goes mad and goes
into an endless loop printing error messages.  This actually happened
to me several time (usually when it gets pager faults or runs out of
disk space).

In any case, how should the bootstrap look like?  What I don't
understand is why the root filesystem etc need a port to the term
server rather than the underlying device used by term.  You can argue
both ways, that the diagnostic messages should follow the system
consoles term session if it is redirected to another output device, or
that they should stay where they are (or being redirected in a lower
level at the device manager).  In other words, I am not sure if the
current way of doing it is really actually wrong.  I can see reasons
for and against it.  Of course, I already make the assumption that we
never want to use a fancy console as system console, so maybe it is
easier for me to go further like this.

In more sophisticated setups, the system console will usually go to a
manager OS session, or to a serial line.  I think that these are the
types of setups we should keep in mind as the ideal model.  Using the
PC hardware kbd+video card as system console will be by far the most
often used setup, so it must work.  But I don't think it should guide
the design, as it is fundamentally flawed.

Thanks,
Marcus