Re: user-level drivers

[olafBuddenhagen]

Hi,

On Mon, May 09, 2011 at 12:07:16AM +0200, Samuel Thibault wrote:

> I've started having a look at Zheng Da's user-level driver integration.
> I've cleaned his tree a bit, and now considering adding patches to
> the debian packages for wider testing.

Great :-)

The ArchHurd folks have been on it for a while BTW; but haven't managed
to successfully build the DDE drivers so far...

> /*
>  *      This routine is created for allocating DMA buffers.
>  *      We are going to get a contiguous physical memory
>  *      and its physical address in addition to the virtual address.
>  */
> routine vm_allocate_contiguous(
>                 host_priv       : host_priv_t;
>                 target_task     : vm_task_t;
>         out     vaddr           : vm_address_t;
>         out     paddr           : vm_address_t;
>                 size            : vm_size_t);

This interface is only acceptable as a proof-of-concept. For upsteam
inclusion, we need to do it properly: the RPC should return a special
memory object (similar to device_map() ), which can then be mapped into
the process address space with vm_map() like any other memory object.
Apart from avoiding some redundant code, and being more elegant, this
will enable all the goodies possible with memory objects: including
various options for the virtual mapping (such as requesting a fixed
address); and the possibility to pass the memory object to other
processes. (That way a manager process could do a limited number of
allocations, and hand the buffers out to unpriviledged driver processes;
and/or the driver processes could hand them out to user processes for
zero-copy buffer management.)

I pointed this out to Zheng Da more or less immediately when he
originally implemented the interface above; and basically he agreed that
the memory object interface would be better -- but never actually
implemented it...

This is one of the reasons why I haven't considered the DDE stuff ready
for upstream inclusion myself.

Another reason is that there is no interface for the userspace drivers
to disable the corresponding kernel drivers, to avoid conflicts -- which
is another thing that was discussed, but not implemented yet...

Also, the userspace code needs various cleanups. (Most notably, we need
a more proper build system for libdde_linux26 and the actual drivers.)
But of course that shouldn't prevent the kernel bits from being merged
(once the proper interfaces are implemented) -- which would actually
make my life much easier, as I could use standard gnumach packages
again :-)

> /*
>  *     enable/disable the specified irq.
>  */
> routine device_irq_enable(
>                master_port     : mach_port_t;
>                irq             : int;
>                status          : char);
>
> Should this be rather split into device_irq_enable/disable and drop the
> status paramter?

Is the disable part actually used at all? AIUI, the kernel IRQ handler
should always disable the line; and the userspace driver only has to
reenable it, after acknowledging and handling the interrupt...

-antrik-