[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: user-level drivers
From: |
olafBuddenhagen |
Subject: |
Re: user-level drivers |
Date: |
Tue, 24 May 2011 12:42:46 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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-
- Re: user-level drivers, (continued)
- Re: user-level drivers, Thomas Schwinge, 2011/05/09
- Re: user-level drivers, Samuel Thibault, 2011/05/09
- Re: user-level drivers, Richard Braun, 2011/05/09
- Re: user-level drivers, Thomas Schwinge, 2011/05/09
- Re: user-level drivers, Richard Braun, 2011/05/09
- Re: user-level drivers, Samuel Thibault, 2011/05/09
- Re: user-level drivers, Richard Braun, 2011/05/10
- Re: user-level drivers, Thomas Schwinge, 2011/05/09
Re: user-level drivers, olafBuddenhagen, 2011/05/26
Re: user-level drivers,
olafBuddenhagen <=