Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

Ingo Molnar
2008-03-04T12:58:42Z

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

>>> 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