Re: Porting KGI to the HURD
From: Steffen Seeger <s.seeger@physik.tu-chemnitz.de>
Date: Mon, 4 Oct 1999 10:39:04 +0200 (CEST)
So, in general drivers contained in Mach do the actual device access, while
the servers provide the application interface, right?
Yes, but this is not essential. Priviliged ``tasks'' can gain access
to IO ports and such, at least for the IA32 architecture.
> To fix this, we want to have the console code outside the (micro)kernel.
This is preferrable, yes. However, there is one point that makes
this a bit problematic. (See also the KGI white paper draft below.)
You have to provide diagnostic messages during boot, which is why
(text) output should be available as early as possible.
This is probably the only reason why we need at least part of the code
in the microkernel. It is essential that the microkernel can print
diagnostic messages without the need to contact any running server.
Mach also has a kernel level debugger, which needs to interact with
the user via the keyboard. But nothing fancy is needed.
One point after the other:
Terminal server with multihead/multiinput:
Yes, KGI was designed from the ground up to do that. On Linux,
this feature is realized by three essential parts:
- exactly one driver per hardware device.
- a central resource management system.
(resource == input and display devices)
- external mappers (I guess 'servers' is the
proper Hurd terminology) that provide applications
access to the devices.
By heart I would put the drivers inside the Mach kernel, while
the mappers could be servers; I am not sure about the resource
manager, but as the drivers have to rely on it, I would
tend to say 'into Mach'.
If it is possible to let the microkernel interact directly with the
driver I think it would be better to implement the resource manager as
a server too.
Mark
Reply to: