Hi Andrew!
The change from
EXPORT_SYMBOL
to
EXPORT_SYMBOL_GPL
for class_simple_* makes the nvidia module useless as it uses several:
nvidia: Unknown symbol class_simple_device_add
nvidia: Unknown symbol class_simple_destroy
nvidia: Unknown symbol class_simple_device_remove
nvidia: Unknown symbol class_simple_create
I don't want to start a flame war and long discussion, just want to ask
wether this change (to _GPL) was intended, and if yes, if there is a way
to fix nvidia kernel modules (or others) using this device management
interface.
Best wishes
Norbert
-------------------------------------------------------------------------------
Norbert Preining <preining AT logic DOT at> Technische Universit?t Wien
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
ABERCRAVE (vb.)
To strongly desire to swing from the pole on the rear footplate of a
bus.
--- Douglas Adams, The Meaning of Liff
On Wed, Oct 27, 2004 at 03:50:52PM +0200, Norbert Preining wrote:
> Hi Andrew!
>
> The change from
> EXPORT_SYMBOL
> to
> EXPORT_SYMBOL_GPL
> for class_simple_* makes the nvidia module useless as it uses several:
> nvidia: Unknown symbol class_simple_device_add
> nvidia: Unknown symbol class_simple_destroy
> nvidia: Unknown symbol class_simple_device_remove
> nvidia: Unknown symbol class_simple_create
I think these changes are only in the Gentoo modified version of the
driver, right? I don't think that nvidia wrote the driver that way.
> I don't want to start a flame war and long discussion, just want to ask
> wether this change (to _GPL) was intended,
Yes it was.
> and if yes, if there is a way to fix nvidia kernel modules (or others)
> using this device management interface.
Get them to change the license on their code.
Good luck,
thanks,
greg k-h
Hi all!
On Mit, 27 Okt 2004, Arjan van de Ven wrote:
> > for class_simple_* makes the nvidia module useless as it uses several:
>
> is this the module as downloaded from nvidia, or as hacked by some
> distro ?
>
On Mit, 27 Okt 2004, Greg KH wrote:
> I think these changes are only in the Gentoo modified version of the
> driver, right? I don't think that nvidia wrote the driver that way.
Yes they did. I downloaded the original NVIDIA-Linux-x86-1.0-6111-pkg1.run,
extracted the source and found in nv.c many things like:
#ifdef NV_CLASS_SIMPLE_PRESENT
class_simple_device_remove(MKDEV(NV_MAJOR_DEVICE_NUMBER, 255));
for (i = 0; i < num_nv_devices; i++)
class_simple_device_remove(MKDEV(NV_MAJOR_DEVICE_NUMBER, i));
class_simple_destroy(class_nvidia);
#endif
and in conftest.sh the check for class_simple_present by checking for
struct class_simple.
> > I don't want to start a flame war and long discussion, just want to ask
> > wether this change (to _GPL) was intended,
>
> Yes it was.
Ok. I can live with that.
> > and if yes, if there is a way to fix nvidia kernel modules (or others)
> > using this device management interface.
>
> Get them to change the license on their code.
Well, funny answer, but not useful for now.
Best wishes
Norbert
-------------------------------------------------------------------------------
Norbert Preining <preining AT logic DOT at> Technische Universit?t Wien
gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
-------------------------------------------------------------------------------
BERY POMEROY
1. The shape of a gourmet's lips. 2. The droplet of saliva which hangs
from them.
--- Douglas Adams, The Meaning of Liff
On Wed, Oct 27, 2004 at 08:37:16AM -0700, Greg KH wrote:
> On Wed, Oct 27, 2004 at 03:50:52PM +0200, Norbert Preining wrote:
> > Hi Andrew!
> >
> > The change from
> > EXPORT_SYMBOL
> > to
> > EXPORT_SYMBOL_GPL
> > for class_simple_* makes the nvidia module useless as it uses several:
> > nvidia: Unknown symbol class_simple_device_add
> > nvidia: Unknown symbol class_simple_destroy
> > nvidia: Unknown symbol class_simple_device_remove
> > nvidia: Unknown symbol class_simple_create
>
> I think these changes are only in the Gentoo modified version of the
> driver, right? I don't think that nvidia wrote the driver that way.
VMware's vmnet is broken by this too. VMware was asked by RedHat to
add udev compatibility to the code, and now you are saying that both
RedHat and VMware were wasting resources for nothing, as you decided that
you'll turn existing interface into GPL only without providing
alternative way?
> > and if yes, if there is a way to fix nvidia kernel modules (or others)
> > using this device management interface.
>
> Get them to change the license on their code.
Why? You have more rights to the sources now than with GPL,
why we should restrict ourself?
Best regards,
Petr Vandrovec
On Wed, 2004-10-27 at 21:17 +0200, Petr Vandrovec wrote:
> VMware's vmnet is broken by this too. VMware was asked by RedHat to
> add udev compatibility to the code, and now you are saying that both
who in Red Hat (notice the space) asked you this? I'm not aware of any
official request to vmware to do this...
>
> I don't want to start a flame war and long discussion, just want to ask
> wether this change (to _GPL) was intended, and if yes, if there is a way
> to fix nvidia kernel modules (or others) using this device management
> interface.
From:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0110.2/0369.html
EXPORT_SYMBOL_GPL() may only be used for new exported symbols, Linus
has spoken. I believe the phrase involved killer penguins with
chainsaws for anybody who changed existing exported interfaces.
not sure if this applies or not to the class_simple interfaces,
probably not but just FYI....
there is no reason NV or who ever can't implement their own non-simple
class ....
Dave.
On Wed, Oct 27, 2004 at 09:55:41PM +0200, Arjan van de Ven wrote:
> On Wed, 2004-10-27 at 21:17 +0200, Petr Vandrovec wrote:
> > VMware's vmnet is broken by this too. VMware was asked by RedHat to
> > add udev compatibility to the code, and now you are saying that both
>
> who in Red Hat (notice the space) asked you this? I'm not aware of any
> official request to vmware to do this...
I assumed that email I received from Warren Togami was official notice that
RHEL4 is going to be udev based and that as vmnet does not currently create
its device nodes in /dev, something should be done about it.
As this request was quite popular, and doing it properly through sysfs
instead of doing several mknods when initscripts run, I filled internal
bug report that RHEL4 will use udev and vmnet should be compatible with
it. And then I implemented some minimal sysfs support.
Week after that I saw first email from Greg changing sysfs_driver_* & co.
to GPL only. I did not worry as this set did not comtain class_simple,
and so I assumed that I'm doing nothing wrong. But today I noticed
that even class_simple is GPL only in -mm.
It was not lot of work, I'd say under 1 hour, but it just does not seem
correct to me, changing symbols visibility after people start using them.
OK, next beta will do several mknods in /etc/init.d/vmware script.
Not technically nice, but working.
Petr Vandrovec
On Wednesday 27 October 2004 10:37 am, Greg KH wrote:
> On Wed, Oct 27, 2004 at 03:50:52PM +0200, Norbert Preining wrote:
> > Hi Andrew!
> >
> > The change from
> > EXPORT_SYMBOL
> > to
> > EXPORT_SYMBOL_GPL
> > for class_simple_* makes the nvidia module useless as it uses several:
> > nvidia: Unknown symbol class_simple_device_add
> > nvidia: Unknown symbol class_simple_destroy
> > nvidia: Unknown symbol class_simple_device_remove
> > nvidia: Unknown symbol class_simple_create
>
> I think these changes are only in the Gentoo modified version of the
> driver, right? I don't think that nvidia wrote the driver that way.
>
> > I don't want to start a flame war and long discussion, just want to ask
> > wether this change (to _GPL) was intended,
>
> Yes it was.
>
I wonder what are the technical merits of this change. I certainly agree
with Pat's assertion that the rest of driver model functions should be used
by in-kernel subsystems (such as PCI, USB, serio etc) only and not exposed
to the outside world. This will allow freely fix/enhance the core without
fear of silently breaking external modules.
But class_simple is itself a limited and contained interface with well-
defined semantic. Which I believe was advertised aat one time as a wrapper
for the objects wanting to plug into hotplug/udev model but either living
outside of established subsystems or within subsystem not yet ready to
implement proper refcounting needed for full-blown sysfs integration.
I think it is a mistake to convert class_simple into GPL-only export.
--
Dmitry
I've thought about this a bunch recently. A lot of people emailed me
privately about it too. Here's my reasoning as to why I did this:
On Wed, Oct 27, 2004 at 08:12:44PM -0500, Dmitry Torokhov wrote:
> I wonder what are the technical merits of this change. I certainly agree
> with Pat's assertion that the rest of driver model functions should be used
> by in-kernel subsystems (such as PCI, USB, serio etc) only and not exposed
> to the outside world. This will allow freely fix/enhance the core without
> fear of silently breaking external modules.
>
> But class_simple is itself a limited and contained interface with well-
> defined semantic. Which I believe was advertised aat one time as a wrapper
> for the objects wanting to plug into hotplug/udev model but either living
> outside of established subsystems or within subsystem not yet ready to
> implement proper refcounting needed for full-blown sysfs integration.
You are right, class_simple is merely a wrapper around the core class
and class_device functions. It makes it easier for a driver subsystem
to implement a very common feature.
See, "wrapper" is the point here. If we were to have someone try to
submit the class_simple code today, after the driver core had the GPL
function exports on them, we would laugh them out of the room on the
grounds that they were wrapping GPL interfaces with a looser one. So,
because of that, I'm going to mark these functions this way.
As to people saying it's futile to try to get companies to change, I
don't buy that. Go look up the history of the EXPORT_SYMBOL_GPL marker
and see who used it first. I know for a fact that because of this
marking on some kernel functions a very large company totally switched
directions and rethought their policies about Linux kernel
drivers/modules. Now that company has plays very nicely with the Linux
kernel community, and contributes a lot of very good, useful, and needed
code, all under the GPL.
So we can change things, little things like this can help everyone out,
even if I'm going to get a ton of nvidia user hate mail directed to me
after the next kernel comes out...
Remember, binary kernel modules are a leach on our community.
thanks,
greg k-h
On Fri, Oct 29, 2004 at 03:55:05PM -0500, Greg KH wrote:
>
> You are right, class_simple is merely a wrapper around the core class
> and class_device functions. It makes it easier for a driver subsystem
> to implement a very common feature.
>
> See, "wrapper" is the point here. If we were to have someone try to
> submit the class_simple code today, after the driver core had the GPL
> function exports on them, we would laugh them out of the room on the
> grounds that they were wrapping GPL interfaces with a looser one. So,
> because of that, I'm going to mark these functions this way.
It is not correct argument. That you turned them to GPL-only just
week before you sent change for class_simple does not negate that they
existed since 2.6.0 as non-GPL exports.
I had code for vmnet which were better than one using class_simple
(class_simple has problem that when you create 256 devices at once,
udevd spawns 256 subprocesses, each wanting ~1MB memory, and all
in runable state; it takes ~10sec until 1GHz 512MB K7 box comes
back to life), but since you changed GPL-ness of driver core, when
you sent first patches I just thought that it is intentional that
you left class_simple untouched in first round and did not complain
immediately when I saw your first GPLization patch.
> As to people saying it's futile to try to get companies to change, I
> don't buy that. Go look up the history of the EXPORT_SYMBOL_GPL marker
> and see who used it first. I know for a fact that because of this
> marking on some kernel functions a very large company totally switched
> directions and rethought their policies about Linux kernel
> drivers/modules. Now that company has plays very nicely with the Linux
> kernel community, and contributes a lot of very good, useful, and needed
> code, all under the GPL.
And it was API which was accessible by non-GPL modules before? Your
way looks more like GIF patent to me - first leave API open for 9 months so
every distribution and all external providers jump on udev, and then
close API and require everybody to relicense code under license of your
choice.
> So we can change things, little things like this can help everyone out,
> even if I'm going to get a ton of nvidia user hate mail directed to me
> after the next kernel comes out...
>
> Remember, binary kernel modules are a leach on our community.
I cannot speak for NVidia, but VMware's modules are opensource. Their
license is just not compatible with GPL, so your argument about binary kernel
modules fall short here.
Thanks,
Petr Vandrovec
P.S.: mknod solution in initscript saves ~60 bytes on disk and 220 bytes
of kernel memory, plus mp3 player does not stop for 10 sec after loading
vmnet ;-) I must thank you for changing availability of your API, it
allowed me to see how to do things more efficiently.
>
> So we can change things, little things like this can help everyone out,
> even if I'm going to get a ton of nvidia user hate mail directed to me
> after the next kernel comes out...
>
> Remember, binary kernel modules are a leach on our community.
True, but now with this code change, you have (acceptable or not) made
binary modules second class citizens of the kernel, they cannot use
the hotplugging or any of the new device model type code, they are
always going to be second best and more of a problem for users, udev
for binary modules is now probably not possible, if you take Linus's
view that binary modules that are not derived from the kernel are not
necessarily GPL then we've made them not able to be as good as other
kernel modules, I don't think we'll annoy any binary module vendors
we'll just piss off users...
personally I thought the whole _GPL thing was meant to denote
interfaces that showed that code was derived from the kernel so should
be under the GPL, interfaces that all drivers should use to work with
Linux are not IMHO proving the code is derived from the kernel, they
still could be derived from another project but just want to be a 2.6
device driver and use hotplug or sysfs.... so they can without fear
lie about their status to use these interfaces... as Linus has said
previously these interfaces are advisory, only lawyers/judges can
decide if they are enforceable....
Dave.
Alle 22:55, venerd? 29 ottobre 2004, Greg KH ha scritto:
>
> So we can change things, little things like this can help everyone out,
> even if I'm going to get a ton of nvidia user hate mail directed to me
> after the next kernel comes out...
>
> Remember, binary kernel modules are a leach on our community.
I'm one of the users biten by this change, and I can undestand your reason;
anyway from my standpoint the situation is that a change that has no
technical motivation (at least to my knowledge) is going to remove an
interface that until now was available, and prevents me to use my card with
new kernels; this is too similar to some closed souce companies behaviour. No
big deal, I can live with that, but if this is the right way to handle that
interface, why this is enforced only now and not from the very first time?
Granted that you have all the rights to do that, may I ask if this is not in
contrast with is stated in this post?
http://www.uwsg.iu.edu/hypermail/linux/kernel/0110.2/0369.html
I understand all your motivation,and I agree with most of them, but I'm asking
if this is the right way to handle this GPL issue...
--
Fabio Coatti http://members.ferrara.linux.it/cova
Ferrara Linux Users Group http://ferrara.linux.it
GnuPG fp:9765 A5B6 6843 17BC A646 BE8C FA56 373A 5374 C703
Old SysOps never die... they simply forget their password.
On Sat, Oct 30, 2004 at 04:44:33PM +0200, Fabio Coatti wrote:
>
> I understand all your motivation,and I agree with most of them, but I'm asking
> if this is the right way to handle this GPL issue...
I have been recently advised that I should not change these symbols, and
so I will not.
Sorry for the noise and wasted bandwidth, will not happen again.
greg k-h
> I have been recently advised that I should not change these symbols, and
> so I will not.
How come the change still hasn't been reversed as of 2.6.10-rc1-mm3?
Luke Maurer
[email protected]
Alle 00:12, mercoled? 10 novembre 2004, Luke Maurer ha scritto:
> > I have been recently advised that I should not change these symbols, and
> > so I will not.
>
> How come the change still hasn't been reversed as of 2.6.10-rc1-mm3?
Also in mm4, still present.
--
Fabio "Cova" Coatti http://members.ferrara.linux.it/cova
Ferrara Linux Users Group http://ferrara.linux.it
GnuPG fp:9765 A5B6 6843 17BC A646 BE8C FA56 373A 5374 C703
Old SysOps never die... they simply forget their password.