bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Mixing raw and cooked devices


From: Niels Möller
Subject: Mixing raw and cooked devices
Date: 04 May 2002 21:04:19 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]