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.