[Top][All Lists]

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

Re: plan to work on user-level device drivers

From: Da Zheng
Subject: Re: plan to work on user-level device drivers
Date: Thu, 16 Jul 2009 12:04:21 +0800
User-agent: Thunderbird (Macintosh/20090605)

olafBuddenhagen@gmx.net wrote:

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 :-)
It's not my description. I just did copy and paste:-)
* 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.
I don't know what is the "iopl" device you are talking about.
I only know iopl, which can change the i/o privilege level. Maybe you can talk more about it on IRC. It seems that gnumach implements ioperm, so we can let a port access by a user program, though it's really not a very good way.
* 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.
Minix3 provides a generic interrupt handler in the kernel and the user-level driver can provide different policies.
I guess we can do the same.

Zheng Da

reply via email to

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