Re: setting standard fds to console in translator libs

[Marcus Brinkmann]

On Fri, Aug 24, 2001 at 01:41:12PM +0200, Niels Möller wrote:
> But isn't it right that messages are output to the console before the
> root filesystem is started?

Hackery hack.  serverboot writes directly to the Mach console.

/dev/console is a translator.  Before the root filesystem, exec, proc, auth
and init are running, it's not much fun being a dynamically linked
translator in the Hurd system ;)

> A reasonable thing to do would be to bind
> that mechanism, whatever it is, to the root filesystem's stderr. Then
> translators could inherit stderr from there, and no one needs to touch
> "/dev/console".

If you look in libdiskfs/console.c, this is what it does.  It writes
directly to the Mach console, which is really the only option for the
root filesystem.  Interestingly it does try hard to print on the console
even if it is not the root filesystem.  I don't know why libdiskfs based
translators get this special treatment over everyone else.
 
> Hmm, I've been assuming that passive translators inherit stdio from
> their parent filesystem when they are started. But perhaps that's not
> true? If they did, it would be enough to have the root filesystem open
> /dev/console, pfinet would inherit that automatically.

It seems to be that case (see libfshelp/fetch-root.c, as well as
start-trans.c and maybe start-trans-long.c).  Only stderr is
iherited.

Should the bootstrap filesystem put the Mach device in its dport?
Or is this too hackish, and it should close the mach device and open
/dev/console properly when it cans, and put this in the dtable slot for
stderr?  When is it safe for ext2fs to open /dev/console?
Maybe in libdiskfs/boot-start.c (diskfs_S_fsys_init) [which is called by
init when proc and auth are up and running)?

As this is the place where the INIT_PORT_* portarray is initiailized, it
seems it would be a good place to correctly initialize the dtable, and close
the Mach device.  Maybe diskfs_console_stdio should just be called a second
time, and it should be rediddled so it knows what to do in this case.

I think you right about this: Usually it is good enough for translators to
inherit the stderr from their parent, which is eventually a real libdiskfs
based filesystem in the usual case.  (OTOH, we might want to boot from
libnetfs based filesystems at some times, and then we want the stuff to work
the same way).  Currently, the real bug seems to be that the bootstrap
filesystem doesn't initialize stderr properly.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de