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

Ingo Molnar
2008-03-04T20:52:11Z

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Tue, 4 Mar 2008, Ingo Molnar wrote:
> >
> > 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?
>
> Ingo, i's simply not possible to put ndiswrapper in user-space sanely.
>
> Drivers are drivers. They'll want (shared) interrupts, they want DMA,
> they want to do things like cli/sti.
>
> The USB drivers *may* be abstracted enough that they don't do any of
> that, but quite frankly, I doubt it.

yeah, i agree that putting it into userspace is quite insane.

it might possible to do it halfways sanely via existing arch/x86/kvm/
infrastructure though. VMX/SVM context will properly emulate the IRQ
flag so cli/sti will work fine, and as long as DMA is properly
quarantined via an iommu it might even not corrupt the rest of the
system. Right now KVM is tailored for full system emulation but there's
no strong reason why it couldnt emulate just a single hardware domain,
with an NDIS driver sitting in that domain - talking to the rest of the
system via hypercalls.

> It sounds like there aren't that many symbols affected at the core:
> the workqueue stuff certainly isn't worth bothering about. The USB
> things that ndiswrapper wants is much more involved, and more likely
> to have issues, but I'm cc'ing Greg here to see.
>
> IOW: I _personally_ don't think there are any license issues, but I do
> want to have the situation clear to people involved.

the ugliest technical aspect of them being in the Linux host kernel is
that NDIS drivers are used to a larger kernel stack, so they very
frequently overflow the Linux kernel stack. Not sure whether recent
versions of ndiswrapper have solved this problem.

Ingo