linux-kernel - Re: GPL question: using large contiguous memory in proprietary driver.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3f43f78b0810141618s64dbeeeew82b41f100890bb5f@mail.gmail.com>
Date:	Tue, 14 Oct 2008 16:18:50 -0700
From:	"Kaz Kylheku" <kkylheku@...il.com>
To:	"Alexey Dobriyan" <adobriyan@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: GPL question: using large contiguous memory in proprietary driver.

On Tue, Oct 14, 2008 at 3:10 PM, Alexey Dobriyan <adobriyan@...il.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/