Bug#419943: linux-2.6: CONFIG_PARAVIRT breaks some external modules

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#419943: linux-2.6: CONFIG_PARAVIRT breaks some external modules

Russ Allbery-2
Package: linux-2.6
Version: 2.6.20-2
Severity: important

The 2.6.20 kernels in unstable for 686 and k7 have CONFIG_PARAVIRT enabled.
This apparently redefines various operations widely used by kernel modules
(or included via inlined functions) to redirect through a paravirts_ops
table, but the paravirts_ops table is marked GPL-only.  This produces
errors like:

FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only
    symbol 'paravirt_ops'

I've seen this problem with both nvidia (non-free) and openafs (free, but
under a non-GPL license -- its code predates the existence of Linux).  Note
that these modules are not intentionally using anything related to paravirt
themselves; it looks like the paravirt.h header file is selectively
overriding functions that are pulled into the modules and which those
modules were previously using without problems.

This problem does not occur on AMD64.

According to:

http://www.mail-archive.com/git-commits-head@.../msg03856.html

this was done because the code is experimental and in flux and the API
will change.  Given that and its effect on out-of-tree modules, could
you disable this option for the time being until the interfaces stabilize?

Thanks!

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#419943: linux-2.6: CONFIG_PARAVIRT breaks some external modules

maximilian attems-9
On Wed, Apr 18, 2007 at 02:47:17PM -0700, Russ Allbery wrote:

>
> The 2.6.20 kernels in unstable for 686 and k7 have CONFIG_PARAVIRT enabled.
> This apparently redefines various operations widely used by kernel modules
> (or included via inlined functions) to redirect through a paravirts_ops
> table, but the paravirts_ops table is marked GPL-only.  This produces
> errors like:
>
> FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only
>     symbol 'paravirt_ops'
>
> I've seen this problem with both nvidia (non-free) and openafs (free, but
> under a non-GPL license -- its code predates the existence of Linux).  Note
> that these modules are not intentionally using anything related to paravirt
> themselves; it looks like the paravirt.h header file is selectively
> overriding functions that are pulled into the modules and which those
> modules were previously using without problems.
>
> This problem does not occur on AMD64.
>
> According to:
>
> http://www.mail-archive.com/git-commits-head@.../msg03856.html
>
> this was done because the code is experimental and in flux and the API
> will change.  Given that and its effect on out-of-tree modules, could
> you disable this option for the time being until the interfaces stabilize?

kvm is a too interesting tech to be disabled,
checkout buildserver trunk builds to see if it is solved in 2.6.21-rcX
-> wiki.debian.org/DebianKernel


 
--
maks


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#419943: linux-2.6: CONFIG_PARAVIRT breaks some external modules

Russ Allbery-2
maximilian attems <[hidden email]> writes:

> kvm is a too interesting tech to be disabled,
> checkout buildserver trunk builds to see if it is solved in 2.6.21-rcX
> -> wiki.debian.org/DebianKernel

Okay, we'll check.  Thanks.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#419943: linux-2.6: CONFIG_PARAVIRT breaks some external modules

Russ Allbery-2
In reply to this post by maximilian attems-9
maximilian attems <[hidden email]> writes:

> kvm is a too interesting tech to be disabled,
> checkout buildserver trunk builds to see if it is solved in 2.6.21-rcX
> -> wiki.debian.org/DebianKernel

The same problem is still present in those builds.

Given the invasiveness of what PARAVIRT does to external module builds, I
think it really needs to be exported not GPL-only if it's going to be
enabled.  Is that a possible option?  From the commit message that set the
GPL-only option, it wasn't done for licensing reasons but rather for
stabilization and release management reasons.  If the decision of the
Debian kernel team is that the interface is actually stable and ready to
be exported, it seems reasonable to also reverse the patch that declared
it not to be.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#419943: linux-2.6: CONFIG_PARAVIRT breaks some external modules

Maximilian Attems-3
On Wed, Apr 18, 2007 at 03:18:22PM -0700, Russ Allbery wrote:
> maximilian attems <[hidden email]> writes:
>
> > kvm is a too interesting tech to be disabled,
> > checkout buildserver trunk builds to see if it is solved in 2.6.21-rcX
> > -> wiki.debian.org/DebianKernel
>
> The same problem is still present in those builds.

well than tell $company to fix their proprietary crap.
kvm has inbetween paravirt and you'll be able to migrate guests
like in xen. it is a strong contender for the virtualisation tech.

xen accounts for a _very_ huge part of the current bts bug flow.
 
> Given the invasiveness of what PARAVIRT does to external module builds, I
> think it really needs to be exported not GPL-only if it's going to be
> enabled.  Is that a possible option?  From the commit message that set the
> GPL-only option, it wasn't done for licensing reasons but rather for
> stabilization and release management reasons.  If the decision of the
> Debian kernel team is that the interface is actually stable and ready to
> be exported, it seems reasonable to also reverse the patch that declared
> it not to be.

the interface is gpl, we won't change upstream decision concerning it.

thanks for the testing

--
maks


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Bug#419943: linux-2.6: CONFIG_PARAVIRT breaks some external modules

Russ Allbery-2
There's an ugly hack of a workaround in OpenAFS that looks like it will
deal with the current CONFIG_PARAVIRT brokenness at the cost of some
performance.  I'll go that route with the next upload.  Hopefully upstream
will remove the (incorrect) GPL-only designation on this interface soon.

NVidia, being non-free, I don't care about as much.  I'll let someone else
will carry the torch for that.

maximilian attems <[hidden email]> writes:

> well than tell $company to fix their proprietary crap.

First of all, using core kernel interfaces that had previously always been
exported to modules (and that are pulled into modules by inline functions
in the kernel even when not called directly) is not broken.  There was a
promise by the linux-kernel folks that interfaces that were previously
generally available would not be changed to GPL-only, which this
essentially breaks.

Second, OpenAFS is not proprietary crap.  It might be DFSG-free crap, but
that's a different judgement.  :)  It is a file system released under an
DFSG-free license whose code predates Linux by several years and is
therefore clearly not a derivative work (and is occasionally used by Linus
as an example of a module that should not be forced to be GPL).  It is in
Debian main.  I realize that it's not your fault (and not even an
intentional decision), but it's frustrating to have RC bugs introduced in
one's package by changes to the kernel that are entirely unrelated and are
not technically necessary (by which I mean the labelling as GPL-only
because the interface is theoretically in flux, not the paravirt changes
themselves which I agree are very cool).

Even if there isn't anything we can do about it, please don't get
indignant at me for being upset that a free software package that we rely
on to be able to run Debian on production servers won't build against the
current Debian kernel.

OpenAFS doesn't even use any of the interfaces in question; they're pulled
in by inlined functions defined elsewhere in the kernel.

Out-of-tree kernel modules are not all proprietary crap.  Some of them are
not GPL for reasons that have nothing to do with vendors and supposed
trade secrets; in this case, it was because OpenAFS is a huge body of code
that acquired hundreds or thousands of independent submissions under the
IBM Public License and at this point it's not feasible to relicense it.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]