[lkml]   [2008]   [Mar]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols

    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.

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

    Don't be silly. When you claim this is the only way things are "halfway
    right", then none of the Linux kernel driver interfaces are even *close*
    to halfway right. Sure, the NDIS ABI has to b more abstracted than the
    Linux kernel one (because it's a binary ABI that survives over multiple
    Windows versions, not a source code API), but the fact is, NDIS is
    designed for kernel-mode, not user mode.

    So asking people to make ndiswrapper be user-mode only is simply not

    The question on the table is not whether we can make it user-mode
    (especially since no major kernel contributor is likely to even care
    enough to really help code anyway), but whether we should let ndiswrapper
    continue using GPLONLY symbols.

    Quite frankly, my position on this has always been that the GPLv2
    explicitly covers _derived_ works only, and that very obviously a Windows
    driver isn't a derived work of the kernel. So as far as I'm concerned,
    ndiswrapper may be distasteful froma technical and support angle, but not
    against the license.

    So I'm personally perfectly happy to say that we should revert that commit
    0aa5bd52d0c49ca56d24584c646e6544ccbb3dc9, but what I've wanted to hear
    from the very beginning was simply to get a list of symbols that currently
    clash, and hear from the people who maintain the symbols whether they
    really meant for that commit to be valid.

    That's the only issue here. Not whether ndiswrapper could do a part of its
    job in user space (because the answer to that latter question is: no.
    Everything is "possible", of course, but realistically, that's simply not
    going to happen).

    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.


     \ /
      Last update: 2008-03-04 18:23    [W:0.024 / U:16.064 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site