bug-hurd
[Top][All Lists]
Advanced

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

Re: plan to work on user-level device drivers


From: olafBuddenhagen
Subject: Re: plan to work on user-level device drivers
Date: Fri, 10 Jul 2009 05:41:33 +0200
User-agent: Mutt/1.5.19 (2009-01-05)

Hi,

On Tue, Jul 07, 2009 at 01:33:17PM +0800, Da Zheng wrote:

> The paper "An I/O System for Mach 3.0" gives very short description of
> the user-level device management: Devices can be managed from
> user-level by vectoring all device  interrupts out to an application's
> thread. The kernel maps to user space  the device's registers, a
> shared page containing some control  information, and some memory for
> handling DMA to/from the device. When  an interrupt comes, a small
> interrupt routine saves any volatile  register state in the shared
> page for later use by the user code, and  then dismisses the
> interrupt, typically by disabling the interrupt  enable bit in the
> device, or by reading an "interrupt-acknowledge"  register. When the
> user thread runs it just invokes the driver's  interrupt routine as if
> it were handling the interrupt in kernel-mode.  After all necessary
> processing, the thread then re-enables interrupts in  the device.

I'm not sure I fully understand all bits from your description; but
overall, it sounds similar to Linux' UIO framework... Which is not very
surprising really :-)

> * I suppose we can map to the user space the device's registers, etc,
> by  using device_map, but I don't know how to do it in practice.

As I already said on IRC, you can use device_map() on the "iopl" device.
This provides a memory object giving access to all MMIO address ranges.

For more fine-grained access control, you'd have to create special
kernel devices mapping only the allowed bits; or have a user space
server mange the access, by providing proxy memory objects... (I needed
something similar for KGI, which is why I had to create the kernel
patches extending the proxy memory object implementation.)

Ideally, we would have special bus drivers that allow mapping only the
relevant regions for each piece of hardware -- with PCI at least this
should be safe IIRC. I didn't go that far with my KGI stuff in the
initial implementation, but this would be the next logical step.

> * Does the small interrupt routine in the kernel already exists?

The problem is that this routine is actually pretty device-specific. In
Linux UIO at least, every driver comes with a small kernel module
handling this -- though I wonder whether it wouldn't be possible to
upload a description is some simplistic "safe" language to the kernel at
runtime, so we don't need to add any "real" (machine) code to the kernel
for each new device.

AFAIK the L4 folks have some paper on interrupt handling -- certainly
worth a look...

> * What is the programming interface provided by the kernel to the
> user-level device driver? Is it still the same set of functions:
> device_* in device.defs?

I don't think that GNU Mach actually does provide any interface for
that, aside from the iopl device... The interrupt and DMA stuff probably
needs to be implemented first.

-antrik-




reply via email to

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