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.
* Init and exec as well initially write on the console through
magic.
* Never never never is any magic stored in a file descriptor array.
* Init opens the console by opening "/dev/console" the normal way,
before starting proc and auth. Init now throws away its magic and
uses the real console for all purposes.
* Init gives proc and auth ordinary file descriptors, pointing at
/dev/console.
* Init hands the console to the filesystem as a new argument in
fsys_init, which gives it to the exec server in exec_init. As
soon as these tasks receive this port, they throw away their
magic and use the real console for all purposes.
Now this has one possible problem: it must be the case that the
console can start up and do work without needing to contact either
proc or auth. So if that's not workable, then we use the less ideal
flavor, in which, after all the first five tasks are going, somebody
(doesn't matter who) opens the console for real, and passes it to
everyone. This requires a whole slew of new RPCs instead of just two
new args, which is why it's less ideal.
Tasks which are able to crash the system or are otherwise important
might well want to be able to use magic to write to the system
console. But this has nothing to do with bootstrapping issues: any
server might be of such importance, even if it wasn't one of the first
five. So what to do when the world falls apart might well bypass the
real console server--but that's independent of bootstrapping, and
should be treated as a separate issue.
What's the magic? Right now it's to open the Mach "console" device,
use mach_open_devstream to create a stdio stream, and then use that.
This is a workable system of magic, but it will break when we remove
the Mach console device. At that point better magic will be needed.
One possible magic is to librarize part of the program that writes on
the hardware, and then crucial servers can just link to that library
if they have the need to be able to scrawl on the screen when the
world is falling apart. This gets subtle quickly, especially in the
bootstrapping case, because there is the need for coordination between
different writers.
I don't have a good solution to where the magic comes from,
ultimately, but it's a separate issue from how things ought to work in
the running system.
Thomas
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
