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-
