[Top][All Lists]

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

oh, this is worth worrying about

From: Thomas Bushnell, BSG
Subject: oh, this is worth worrying about
Date: 21 Apr 2004 22:19:39 -0700
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

So in re-reading libdiskfs/boot-start.c, there is a loose end with
consoles that still needs to be sorted out, which is that by the time
the whole system is running, stdin/stdout/stderr for all the startup
programs should be a fully running console program.  I don't think
that is happening now.  When boot happens, libdiskfs opens the console
directly with the kernel and writes things on it (and if pausing is
enabled, reads too).  

Then the filesystem provides to the exec server and the startup
service raw this Mach device port as fds 0, 1, and 2.

The startup program opens the Mach console device itself, and then
uses mach_open_devstream to get stdio ports onto it, for stdin,
stdout, and stderr.

Then it takes its own inherited file descriptors 0, 1, and 2, and puts
them into the default descriptor table.  Those will be the Mach
console device port (not a Hurd IO port at all) which it inherited
from the filesystem.  So auth, proc, and *everything else* end up
inheriting this, except that getty/login open file descriptors

All this is really quite wrong.  Something special must happen at the
very beginning, sure.  But by the time the system is fully running,
everyone should have a file descriptor pointing at the system console
*through a normal Hurd port* in the *normal way*.

Fortunately translator startup doesn't inherit descriptors from the
filesystem.  So the tasks which get the bogus file descriptors are:

the fs, exec, init, auth, proc, and everything that init starts from
ttys that doesn't reopen them itself.

We can't rely on starting a fancy console program until auth and proc
are running, so that means that we have to wait until init has started
them.  That means that maybe init should open the console for real.

Then good console ports should get communicated back to the fs, auth,
proc, and exec.

Or, alternatively, a real console port should be added to some of the
bootstrapping RPCs or new bootstrapping RPCs created to handle it
magically the way the other initial ports are.


reply via email to

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