On Wed, May 08, 2019 at 02:28:21PM +0200, Sebastian Gottschall wrote:
> so the question is if it isnt possible to create a EXPORT_SYMBOL variant
> which includes acceptable license models, but still restricts unacceptable
> licenses
It's not very difficult, "acceptable" license models are all
Am 07.05.2019 um 12:31 schrieb David Laight:
...
So I don't really see a problem with Andy's patch. If we want to annoy
external non-GPL modules as much as possible, sure, that's for a separate
discussion though (and I am sure many people would agree to that).
Proposal to get rid of
...
> So I don't really see a problem with Andy's patch. If we want to annoy
> external non-GPL modules as much as possible, sure, that's for a separate
> discussion though (and I am sure many people would agree to that).
> Proposal to get rid of EXPORT_SYMBOL in favor of EXPORT_SYMBOL_GPL would
>
On Sun, 5 May 2019, Rik van Riel wrote:
> > Using fpu code in kernel space in a kernel module is a derived work of
> > the kernel itself? dont get me wrong, but this is absurd. i mean you
> > limit the use of cpu instructions. the use of cpu instructions should
> > be free of any licensing
On Sat, 2019-05-04 at 04:28 +0200, Sebastian Gottschall wrote:
> Using fpu code in kernel space in a kernel module is a derived work
> of
> the kernel itself?
> dont get me wrong, but this is absurd. i mean you limit the use of
> cpu
> instructions. the use
> of cpu instructions should be free
On Fri, 3 May 2019, Jiri Kosina wrote:
> > Please don't start this. We have everything _GPL that is used for FPU
> > related code and only a few functions are exported because KVM needs it.
>
> That's not completely true. There are a lot of static inlines out there,
> which basically made it
On Sat, May 04, 2019 at 04:28:17AM +0200, Sebastian Gottschall wrote:
>
> Am 04.05.2019 um 02:47 schrieb Ingo Molnar:
> > * Jiri Kosina wrote:
> >
> > > On Thu, 2 May 2019, Sebastian Andrzej Siewior wrote:
> > >
> > > > Please don't start this. We have everything _GPL that is used for FPU
> >
Am 04.05.2019 um 02:47 schrieb Ingo Molnar:
* Jiri Kosina wrote:
On Thu, 2 May 2019, Sebastian Andrzej Siewior wrote:
Please don't start this. We have everything _GPL that is used for FPU
related code and only a few functions are exported because KVM needs it.
That's not completely true.
* Jiri Kosina wrote:
> On Thu, 2 May 2019, Sebastian Andrzej Siewior wrote:
>
> > Please don't start this. We have everything _GPL that is used for FPU
> > related code and only a few functions are exported because KVM needs it.
>
> That's not completely true. There are a lot of static
On Fri, May 03, 2019 at 11:54:54AM -0700, Andy Lutomirski wrote:
> I don’t think I or has said we should try to make these interfaces
> immutable.
How else would you have a stable interface for OOT modules? If at all,
that is.
> What I’m saying is that, since we’re exporting the symbol anyway
>
> On May 3, 2019, at 11:07 AM, Borislav Petkov wrote:
>
>> On Fri, May 03, 2019 at 11:21:15AM -0600, Paolo Bonzini wrote:
>> Your observation that the API only exists on x86 and s390 has no bearing
>> to whether the functions should be EXPORT_SYMBOL_GPL or EXPORT_SYMBOL.
>> ARM has
On Thu, 2 May 2019, Sebastian Andrzej Siewior wrote:
> Please don't start this. We have everything _GPL that is used for FPU
> related code and only a few functions are exported because KVM needs it.
That's not completely true. There are a lot of static inlines out there,
which basically made
On Fri, May 03, 2019 at 11:21:15AM -0600, Paolo Bonzini wrote:
> Your observation that the API only exists on x86 and s390 has no bearing
> to whether the functions should be EXPORT_SYMBOL_GPL or EXPORT_SYMBOL.
> ARM has kernel_neon_begin/end, PPC has enable/disable_kernel_altivec.
> It's just
On 02/05/19 10:55, Borislav Petkov wrote:
> On Thu, May 02, 2019 at 09:29:01AM -0700, Andy Lutomirski wrote:
>> I'm not saying that we should export things for ZFS's benefit. But,
>> as far as I know, _GPL means "this interface is sufficiently specific
>> to Linux details that we think that any
On Thu, May 02, 2019 at 09:29:01AM -0700, Andy Lutomirski wrote:
> I'm not saying that we should export things for ZFS's benefit. But,
> as far as I know, _GPL means "this interface is sufficiently specific
> to Linux details that we think that any user must be a derived work".
> I don't think
On Thu, May 2, 2019 at 8:41 AM Sebastian Andrzej Siewior
wrote:
>
> On 2019-05-02 07:42:14 [-0700], Andy Lutomirski wrote:
> > The FPU is not a super-Linuxy internal detail, so remove the _GPL
> > from its export. Without something like this patch, it's impossible
> > for even highly
On 2019-05-02 07:42:14 [-0700], Andy Lutomirski wrote:
> The FPU is not a super-Linuxy internal detail, so remove the _GPL
> from its export. Without something like this patch, it's impossible
> for even highly license-respecting non-GPL modules to use the FPU,
> which seems silly to me. After
The FPU is not a super-Linuxy internal detail, so remove the _GPL
from its export. Without something like this patch, it's impossible
for even highly license-respecting non-GPL modules to use the FPU,
which seems silly to me. After all, the FPU is a CPU feature, not
really a kernel feature at
18 matches
Mail list logo
