Re: setting standard fds to console in translator libs

[Marcus Brinkmann]

On Fri, Aug 24, 2001 at 03:31:08PM +0200, Niels Möller wrote:
> > 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)?
> 
> What about this: Before the root filesystem is running (what starts
> before the root filesystem? init? Or only the kernel?), create a port
> that looks like an ordinary i/o port, but which sends all messages to
> the mach console. This thing might be the mach console itself, or some
> thread in the kernel or init. Make sure the root filesystem uses this
> port for it's stderr.

The order is this:

GNU Mach -> serverboot -> root fs, exec -> proc, auth, init

(of course, what really happens in the last steps is a lot of back and forth
passing information like ports around).

The root filesystem already does open the console device (did you look at
diskfs_console_stdio?), and it sets stderr to a stream pointing to that
device.  But I don't think it sets this stream as file descriptor 2.
If it would do that, others could inherit it.  Note: I don't know enough
about the file descriptor stuff to see if glibc would be happy with setting
this manually, and how much is involved to trick glibc into thinking that
this file descriptor is sane and the one to inherit.  It shouldn't be too
hard to get this working, though.

So, I think this part is done quite easily by adding some lines to
diskfs_console_stdio, and would already be enough to make Moritz happy.

> Later, when /dev/console is started (if not earlier, this should
> happen as soon as some init script sends data to the console), the
> console tells init about that, and gets init to either give away the
> root filesystems stderr port to the console, or if that's too hard,
> start forwarding messages to the console.

I am not sure on that.  I don't think /dev/console should do any reporting
(I don't see any reason for that).  However, /dev/console is not always
available (consider the first booting with an empty /dev, where the fallback
console is installed in /tmp).  I am not sure it is necessary given the
inheritance of the Mach console device above.

But if, I think that the boot filesystem should just at some time in the
init/proc/auth negotiation it is involved in decide that *if* /dev/console
is there, we can use it, and try to open it properly and redirect std* to
it, closing the Mach device.  If this would fail, for example because
/dev/console doesn't exist, it could continue to use the Mach device.

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