The talk about child hurds and faking devices has brought a question to my mind, which I hope you can shed some light on.
We do need some abstraction that represents control over the hardware. Like the Mach master device port. If you have a send right to that, you can do whatever you like with the hardware. The available hardware is cut up into logical devices, like ethernet device, serial devica, vga console, etc. Typically, all the devices are things implemented in the Mach kernel. However, we will also have device-like things that are implemented in userspace. One example is Markus' new console code, another is the mouse translator. It will be even more true if we ever get to move real hardware drivers from Mach to userspace. To me, it would make sense to hook the console server into the device list accessible through the master device port. So that you can ask the device port for access to the console, just like you could ask it for access to the serial hardware. Consider a parent hurd and a child hurd. The parent has access to the real Mach device port, and when booting, Markus' console code will be started, get access to vga hardware, and do its thing. However, when booting a child hurd, it shouldn't try to get access to vga hardware (and it should fail if it tries to), it should just ask for a console device, and get connected to the user-level console code that lives in the parent hurd. So it seems natural to have a "server" that provides access to available devices, the clients of which should not need to know which devices are implemented in Mach and which are some user-level process. For instance, the code bringing up the console could look both for the console device and a raw-vga device, and open whichever is available to it. Does this make any sense? Does the Mach device master port fit these requirements, and if not, how far away is it? After writing this, it occurs to me that this get-access-to-hardware service is actually a naming service, so it would also make a lot of sense to attach it to some node in the filesystem, say "/devices", as soon as a filesystem is brought up. Note that it should probably not be "/dev", /dev should be populated with translators (e.g. storeio) , which could in turn open raw devices in /devices, instead of grabbing the Mach master device port. Some of the simpler nodes in /devices could have plain symlinks from /dev, but that's not the general case. Best regards, /Niels _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
