Date: Mon, 4 Oct 1999 15:03:17 +0200 From: Marcus Brinkmann <[EMAIL PROTECTED]>
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
