* Pavel Roskin <proski@gnu.org> wrote:

quoted text
>>> ndiswrapper contains essentially two drivers in one - PCI and USB. 
>>> The PCI driver uses DMA, which should be a strong argument for 
>>> keeping it in the kernel.
>>
>> how exactly does it use DMA - how does it allocate the memory it 
>> later on DMAs into, and how does it typically program that DMA target 
>> - is there any control over that in the NDIS protocol - or will NDIS 
>> drivers just write random addresses to the mmio space and then the 
>> hardware does DMA to/from those addresses? [without the NDIS 
>> framework having any knowledge about the encoding of those bits?]
>
> Sorry for delay.  I'm really not sure.  The maintainer of ndiswrapper 
> is currently offline, and I'm just trying to take care of the basic 
> stuff.
>
> All I can say is NdisMAllocateSharedMemory maps to 
> dma_alloc_coherent(), and there are some references to scatter-gather 
> lists.  There is a call to dma_map_single(), which is ultimately 
> called by the Tx function net_dev->hard_start_xmit.
>
> I understand there is some control from NDIS.  At least it can request 
> memory available for DMA.

so ... i suspect the requirement would be for 
NdisMAllocateSharedMemory() to return a linear address that is DMA-able, 
and to properly map it to a physical address via dma_map_single(). I can 
see only one complication in pushing this to user-space: physical 
fragmentation of allocations. What are the typical buffer sizes that 
NDIS drivers request from the kernel? Is it frequently above 4K?

you could try to create a syscall-ish API towards the kernel that allows 
DMA, it would have the following functionality:

- allocate a piece of continuous memory and return its physical address
  plus its linear address as well and map the linear address into the
  user-space pagetables. This memory would be unfragmented on the 
  physical side.

you probably could even use/hack hugetlbfs right now to achieve 
something very similar. (hugetlbfs pages are unfragmented 2MB 
largepages)

if the NDIS API is done halfways right, then there's no need for any of 
these buffers to be in kernel-space and for the driver to run in kernel 
space.

i think someone should really try to push a known-well-behaving NDIS 
driver (for which a Linux driver exists too) down to user-space. NDIS 
has been around since Netware so it's a pretty well-understood driver 
model. And with an iommu it could all be made a safe sandbox as well (an 
NDIS device could never exit its sandbox).

	Ingo
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/