Re: Porting KGI to the HURD
Date: Mon, 4 Oct 1999 15:03:17 +0200
From: Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>
On Mon, Oct 04, 1999 at 10:39:04AM +0200, Steffen Seeger wrote:
>
> So, in general drivers contained in Mach do the actual device
> access, while the servers provide the application interface,
> right?
Well, yes. The main ABI is of course the GNU C library, which
communicates directly with Mach and the Hurd servers. Some
applications may choose to communicate with Mach directly, or with
the Hurd servers, but most aplications only use the POSIX interface
exposed by glibc.
Please avoid using Mach facilities as much as possible. You'll
probably only need them for really low level things. And even then it
may be a good idea to put an abstraction layer in between.
So, in a real microkernel model, the kernel would be so small that no
diagnostics is printed, so you don't need a console subsystem at that stage
(but the console would be started up very early).
You'll always need a way to display diagnostic message from within the
kernel itself. However, this doesn't need to be a full-fledged
terminal device.
Currently, we have to deal with a mixture, which complicates things a bit.
And is probably unavoidable.
Beside the actual console logging (which could be solved using the kernel
message device and klogd), I see two more problems: The Mach kernel
debugger needs a console device. The Hurd bootstrap tasks open a mach device
stream to the "console" device. So it seems we indeed have the need for a
console device in GNU Mach.
The kernel message device is no alternative for actual console
logging. You want the messages to get out even when the piece of
software that is monitoring the kernel log is hosed.
But I wouldn't say that this couldn't be fixed. I could imagine that we
leave the dumb console device in GNU Mach active for this purpose. I could
imagine that we replace it with a minimal console that can be controlled
by the KGI (which resides completely outside the kernel). I can imagine
moving all device drivers outside GNU Mach (using the OSToolKit?), which
solves this problem in a nice way (but has other problems).
Note that I can't offer solutions, I don't know enough about the issues
involved. But I hope I can point out some possible alternatives and add
another point of view in this discussion.
The point is that we should be careful not to introduce too many
interdepencies. A driver which needs a console server which needs the
bootstrap filesystem server might not a good idea.
Mark
Reply to: