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 themselves. 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. Thomas _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
