[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-