GPL question: using large contiguous memory in proprietary driver. - Kernel

This is a discussion on GPL question: using large contiguous memory in proprietary driver. - Kernel ; Hi all, I have the following question. Suppose that some proprietary driver (otherwise completely clean, based only on non-GPL symbols) requires a large buffer of physically contiguous memory. A GPL-ed driver could get this memory by having some boot-time code ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: GPL question: using large contiguous memory in proprietary driver.

  1. GPL question: using large contiguous memory in proprietary driver.

    Hi all,

    I have the following question. Suppose that some proprietary driver
    (otherwise completely clean, based only on non-GPL symbols)
    requires a large buffer of physically contiguous memory.

    A GPL-ed driver could get this memory by having some boot-time
    code compiled into the kernel which calls bootmem_alloc during
    kernel initialization. This function would stash the address of the
    memory into some global variable which is exported for the
    module to use.

    How do you solve this problem in a proprietary driver? It seems
    like the above solution taints the kernel, because the kernel
    provides a symbol which exists only for the sake of supporting
    a proprietary driver.

    Would it be okay to have a mechanism like this:
    Suppose that on the kernel command line, you could
    request a boot-time memory allocation and give it a name.
    For instance, the parameter:

    boot_alloc=foo,8192K

    would create an 8192 kilobyte allocation, and associate it
    with the string "foo". A non-GPL function would be provided to
    find the address of this memory, using the string "foo"
    as the key. The proprietary driver would document the
    requirement that it needs a memory region of at least
    8192K, under the name "foo".

    Help!
    --
    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/

  2. Re: GPL question: using large contiguous memory in proprietary driver.

    On Tue, Oct 14, 2008 at 02:56:40PM -0700, Kaz Kylheku wrote:
    > I have the following question. Suppose that some proprietary driver
    > (otherwise completely clean, based only on non-GPL symbols)


    You have strange notion of "clean".

    > requires a large buffer of physically contiguous memory.
    >
    > A GPL-ed driver could get this memory by having some boot-time
    > code compiled into the kernel which calls bootmem_alloc during
    > kernel initialization. This function would stash the address of the
    > memory into some global variable which is exported for the
    > module to use.
    >
    > How do you solve this problem in a proprietary driver?


    :-)

    > It seems
    > like the above solution taints the kernel, because the kernel
    > provides a symbol which exists only for the sake of supporting
    > a proprietary driver.
    >
    > Would it be okay to have a mechanism like this:
    > Suppose that on the kernel command line, you could
    > request a boot-time memory allocation and give it a name.
    > For instance, the parameter:
    >
    > boot_alloc=foo,8192K
    >
    > would create an 8192 kilobyte allocation, and associate it
    > with the string "foo". A non-GPL function would be provided to
    > find the address of this memory, using the string "foo"
    > as the key. The proprietary driver would document the
    > requirement that it needs a memory region of at least
    > 8192K, under the name "foo".
    >
    > Help!


    Since the code to reserve memory and code to find by name won't be
    accepted, the question is rather pointless.
    --
    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/

  3. Re: GPL question: using large contiguous memory in proprietary driver.

    On Tue, 2008-10-14 at 14:56 -0700, Kaz Kylheku wrote:
    > Hi all,
    >
    > I have the following question. Suppose that some proprietary driver
    > (otherwise completely clean, based only on non-GPL symbols)
    > requires a large buffer of physically contiguous memory.
    >
    > A GPL-ed driver could get this memory by having some boot-time
    > code compiled into the kernel which calls bootmem_alloc during
    > kernel initialization. This function would stash the address of the
    > memory into some global variable which is exported for the
    > module to use.
    >
    > How do you solve this problem in a proprietary driver? It seems
    > like the above solution taints the kernel, because the kernel
    > provides a symbol which exists only for the sake of supporting
    > a proprietary driver.
    >
    > Would it be okay to have a mechanism like this:
    > Suppose that on the kernel command line, you could
    > request a boot-time memory allocation and give it a name.
    > For instance, the parameter:
    >
    > boot_alloc=foo,8192K
    >
    > would create an 8192 kilobyte allocation, and associate it
    > with the string "foo". A non-GPL function would be provided to
    > find the address of this memory, using the string "foo"
    > as the key. The proprietary driver would document the
    > requirement that it needs a memory region of at least
    > 8192K, under the name "foo".


    Any GPL driver doing that deserves to be taken out and shot just as bad
    as anyone else ;-)

    That said, I don't think you'll find much sympathy here for non-GPL
    kernel modules.

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

  4. Re: GPL question: using large contiguous memory in proprietary driver.

    Kaz Kylheku wrote:

    > I have the following question. Suppose that some proprietary driver
    > (otherwise completely clean, based only on non-GPL symbols)


    The fact that it's not using GPL symbols does not actually mean that the
    driver is not a derivative work of the kernel (and thus subject to the GPL).

    > Would it be okay to have a mechanism like this:




    You should probably talk to a lawyer specializing in IP law.

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

  5. Re: GPL question: using large contiguous memory in proprietary driver.

    On Tue, Oct 14, 2008 at 3:12 PM, Chris Friesen wrote:
    > Kaz Kylheku wrote:
    >
    >> I have the following question. Suppose that some proprietary driver
    >> (otherwise completely clean, based only on non-GPL symbols)

    >
    > The fact that it's not using GPL symbols does not actually mean that the
    > driver is not a derivative work of the kernel (and thus subject to the GPL).


    But thanks to the gracious tolerance of the kernel development
    community, such drivers are permitted to exist. That is the question:
    setting aside GPL chapter and verse, could that tolerance extend
    to allow such a driver to get a piece of boot-time memory, and if so,
    what mechanism would be tolerated?
    --
    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/

  6. Re: GPL question: using large contiguous memory in proprietary driver.

    On Tue, Oct 14, 2008 at 3:10 PM, Alexey Dobriyan wrote:
    > On Tue, Oct 14, 2008 at 02:56:40PM -0700, Kaz Kylheku wrote:
    >> Would it be okay to have a mechanism like this:
    >> Suppose that on the kernel command line, you could
    >> request a boot-time memory allocation and give it a name.
    >> For instance, the parameter:
    >>
    >> boot_alloc=foo,8192K
    >>
    >> would create an 8192 kilobyte allocation, and associate it
    >> with the string "foo". A non-GPL function would be provided to
    >> find the address of this memory, using the string "foo"
    >> as the key. The proprietary driver would document the
    >> requirement that it needs a memory region of at least
    >> 8192K, under the name "foo".
    >>
    >> Help!

    >
    > Since the code to reserve memory and code to find by name won't be
    > accepted, the question is rather pointless.


    Suppose that this problem is being solved by people who maintain
    their own OS distribution, based around a customized Linux kernel,
    targetting a very specific piece of hardware, manufactured by
    them.

    So there is no situation in which users of a mainstream
    distribution would be asked to patched their kernels to
    be able to use this driver. Their kernels would already
    come that way from this distribution.

    The driver in question is specific to the hardware, and uses code
    licensed from the vendor of some chips that are used on the
    embedded system, so the developers don't have the option of
    open-sourcing it, however attractive that might be.
    --
    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/

  7. Re: GPL question: using large contiguous memory in proprietary driver.

    On Tue, Oct 14, 2008 at 3:12 PM, Chris Friesen wrote:
    > Kaz Kylheku wrote:
    >
    >> I have the following question. Suppose that some proprietary driver
    >> (otherwise completely clean, based only on non-GPL symbols)

    >
    > The fact that it's not using GPL symbols does not actually mean that the
    > driver is not a derivative work of the kernel (and thus subject to the GPL).


    One more thing. Here is another question.

    Suppose that this proprietary driver can be moved entirely into user
    space. It still needs the contiguous buffer, but it can
    map it using mmap, given the address.

    Can this proprietary user-space application read the address
    of this buffer from a custom /proc entry?

    Or does this dependency make it a derived work of the kernel?
    --
    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/

  8. Re: GPL question: using large contiguous memory in proprietary driver.

    Kaz Kylheku wrote:
    > On Tue, Oct 14, 2008 at 3:12 PM, Chris Friesen
    > wrote:
    >
    >> Kaz Kylheku wrote:
    >>
    >>
    >>> I have the following question. Suppose that some proprietary
    >>> driver (otherwise completely clean, based only on non-GPL
    >>> symbols)

    >>
    >> The fact that it's not using GPL symbols does not actually mean
    >> that the driver is not a derivative work of the kernel (and thus
    >> subject to the GPL).

    >
    >
    > But thanks to the gracious tolerance of the kernel development
    > community, such drivers are permitted to exist.


    If you're thinking of something like the Nvidia driver, the binary
    portion of that driver is cross-platform and is not a derivative work of
    the kernel.

    If you sit down and write a new driver for linux, is is arguable that it
    is in fact a derivative work of the kernel and is thus subject to the GPL.

    This may of course vary based on location, but I strongly suggest that
    you consult suitable legal advice before proceeding.

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

  9. Re: GPL question: using large contiguous memory in proprietary driver.

    Chris Friesen wrote:
    > If you sit down and write a new driver for linux, is is arguable that
    > it is in fact a derivative work of the kernel and is thus subject to
    > the GPL.


    This is essentially the argument that SCO used when they sued IBM over
    IBM's printing technology.
    --
    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/

  10. Re: GPL question: using large contiguous memory in proprietary driver.

    On Tue, Oct 14, 2008 at 04:23:37PM -0700, Kaz Kylheku wrote:
    > On Tue, Oct 14, 2008 at 3:12 PM, Chris Friesen wrote:
    > > Kaz Kylheku wrote:
    > >
    > >> I have the following question. Suppose that some proprietary driver
    > >> (otherwise completely clean, based only on non-GPL symbols)

    > >
    > > The fact that it's not using GPL symbols does not actually mean that the
    > > driver is not a derivative work of the kernel (and thus subject to the GPL).

    >
    > But thanks to the gracious tolerance of the kernel development
    > community, such drivers are permitted to exist.
    >...


    "tolerance" = "it has not yet been brought to court"

    There is no explicit permission of any kind for doing this, and it can
    be might to court in any country based on the local copyright law at
    any time.

    cu
    Adrian

    --

    "Is there not promise of rain?" Ling Tan asked suddenly out
    of the darkness. There had been need of rain for many days.
    "Only a promise," Lao Er said.
    Pearl S. Buck - Dragon Seed

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

  11. Re: GPL question: using large contiguous memory in proprietary driver.

    > But thanks to the gracious tolerance of the kernel development
    > community, such drivers are permitted to exist. That is the question:


    Thats an interesting interpretation and not one I'd want to rely upon.

    > setting aside GPL chapter and verse, could that tolerance extend
    > to allow such a driver to get a piece of boot-time memory, and if so,
    > what mechanism would be tolerated?


    You should discuss such matters with your lawyer. What you are trying to
    ask I think is a question about what constitutes an independant work, and
    that is a legal not a technical question.

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

  12. Re: GPL question: using large contiguous memory in proprietary driver.

    On Wednesday 15 October 2008 10:39, Kaz Kylheku wrote:
    > On Tue, Oct 14, 2008 at 3:12 PM, Chris Friesen wrote:
    > > Kaz Kylheku wrote:
    > >> I have the following question. Suppose that some proprietary driver
    > >> (otherwise completely clean, based only on non-GPL symbols)

    > >
    > > The fact that it's not using GPL symbols does not actually mean that the
    > > driver is not a derivative work of the kernel (and thus subject to the
    > > GPL).

    >
    > One more thing. Here is another question.


    I don't know if there are any lawyers on this list, and definitely you
    shouldn't take this kind of advice from answers here.


    > Suppose that this proprietary driver can be moved entirely into user
    > space. It still needs the contiguous buffer, but it can
    > map it using mmap, given the address.


    The kernel carries a license that states:

    'NOTE! This copyright does *not* cover user programs that use kernel
    services by normal system calls - this is merely considered normal use
    of the kernel, and does *not* fall under the heading of "derived work".'

    Which could be relevant.


    > Can this proprietary user-space application read the address
    > of this buffer from a custom /proc entry?
    >
    > Or does this dependency make it a derived work of the kernel?


    I would be careful if you were to explicitly modify the kernel you
    distribute with the driver in order to allow your driver to live
    in userspace. No idea whether that is safe.

    However, we do have this pagemap proc API existing in the kernel
    which is a kernel service that can be used with a normal system
    call. It returns the page frame number that a given virtual address
    is mapped to. (God knows WTF that is supposed to be a remotely good
    idea for the kernel to export, but there you have it.)

    Whether that helps you or allows you to comply with your obligations,
    I don't know.

    Or, as an alternative, why not instead run the gauntlet with your
    other licensor and tell them their license isn't acceptable because
    your product contains code with incompatible restrictions?!
    --
    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/

  13. Re: GPL question: using large contiguous memory in proprietary driver.

    >>>>> "Kaz" == Kaz Kylheku writes:

    Kaz> On Tue, Oct 14, 2008 at 3:12 PM, Chris Friesen wrote:
    >> Kaz Kylheku wrote:
    >>
    >>> I have the following question. Suppose that some proprietary driver
    >>> (otherwise completely clean, based only on non-GPL symbols)

    >>
    >> The fact that it's not using GPL symbols does not actually mean that the
    >> driver is not a derivative work of the kernel (and thus subject to the GPL).


    Kaz> But thanks to the gracious tolerance of the kernel development
    Kaz> community, such drivers are permitted to exist. That is the question:
    Kaz> setting aside GPL chapter and verse, could that tolerance extend
    Kaz> to allow such a driver to get a piece of boot-time memory, and if so,
    Kaz> what mechanism would be tolerated?

    Why doesn't your hardware support Scatter Gather Lists instead? Then
    you could setup virtual contiguous memory regions to use, but the
    underlying physical RAM could be fragmented and you wouldn't care.

    Seems like the more sensible solution. Also, more people would be
    *happy* to help you in that case, as opposed to the "I need a large
    block of contiguous RAM" request which pops up a couple of times a
    year on this list and pretty much always gets shot down.

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

  14. Re: GPL question: using large contiguous memory in proprietary driver.

    Kaz Kylheku wrote:
    > Hi all,
    >
    > I have the following question. Suppose that some proprietary driver
    > (otherwise completely clean, based only on non-GPL symbols)
    > requires a large buffer of physically contiguous memory.
    >
    > A GPL-ed driver could get this memory by having some boot-time
    > code compiled into the kernel which calls bootmem_alloc during
    > kernel initialization. This function would stash the address of the
    > memory into some global variable which is exported for the
    > module to use.
    >
    > How do you solve this problem in a proprietary driver? It seems
    > like the above solution taints the kernel, because the kernel
    > provides a symbol which exists only for the sake of supporting
    > a proprietary driver.
    >
    > Would it be okay to have a mechanism like this:
    > Suppose that on the kernel command line, you could
    > request a boot-time memory allocation and give it a name.
    > For instance, the parameter:
    >
    > boot_alloc=foo,8192K
    >
    > would create an 8192 kilobyte allocation, and associate it
    > with the string "foo". A non-GPL function would be provided to
    > find the address of this memory, using the string "foo"
    > as the key. The proprietary driver would document the
    > requirement that it needs a memory region of at least
    > 8192K, under the name "foo".
    >
    > Help!


    Hardware with scatter/gatcher capabilites would be best. But short
    of that, you could just use the bigphysarea patch. GOOGLE for it and you'll
    find a version suitable for most kernel versions. I've been using it for years with
    a GPL driver but even if the driver wasn't GPL I would still be using it.

    I sure wish it could be included in the kernel??

    There really aren't many good reasons not to GPL your driver BTW.

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

+ Reply to Thread