Re: Device drivers implemented as translators?
> is it possible/practical to implement device drivers under Hurd as
> translators in user space? I think of removing all the device drivers
> from GNUmach (or whatever micro kernel we use then ;), which already
> make this micro kernel quite big. Then, you could for example settrans
> /hurd/devices/floppy to /dev/fd0 and had your floppy drive available
> as /dev/fd0. What do you think about it? Is it practical?
> This would also make the Hurd more independent from the underlying
> micro kernel, because it comes with its own device drivers.
I don't know about the Hurd in its current stage, though it would be a
nice feature.
If we switch to L4, it would be mandatory anyway. L4 makes it necessary
to implement device drivers in user-land. Actually, interrupts are delivered
to a user-land thread which registers with it and which is free to handle
that interrupt the way it sees fit. Accessing devices is done directly
by mapping the page that contains the devices into the task that contains
the respective interrupt-handler-thread. on a pc, where the devices are
(mostly) mapped in a separate i/o space, this space is mapped as a (virtual)
memory page.
The problem I see here is in reusing existing device drivers from other
OS like e.g. Linux. Such drivers assume that they access the device with
blocked interrupts (cli/sti) and a user-land multithreaded interrupt-handler
(a.k.a device driver server) must then use locks to insure integrity.
Look at the implementation of L4Linux on L4-Fiasco if you want to get an
idea of real code.
BTW, if we decide to virtualize the ukernel interface in the hurd (libvk...),
we should probably also virtualize the system somewhere (libsystem, libpc..),
by adding abstractions to dma, pci-bus, interrupt-controller, etc. Even
if we do so, using foreign driver code (a.k.a. Linux drivers from OSKit)
will still be a bit of a challange. I don't know any universal solution
to this problem. l4-hackers or others may have thought about this more
thoroughly.
Thanks,
-Farid.
--
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji@ob.kamp.net
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.
Reply to: