A "new driver model" and EXPORT_SYMBOL_GPL question

A "new driver model" and EXPORT_SYMBOL_GPL question

[Michal Jaegermann]

It dawned on me only now that a "new driver model" introduced
in patches from GKH export symbols like that:

EXPORT_SYMBOL_GPL(class_create);
EXPORT_SYMBOL_GPL(class_destroy);

and so on.  The problem is that corresponding old symbols, which
are still present in 2.6.12, were exported

EXPORT_SYMBOL(class_simple_create);
EXPORT_SYMBOL(class_simple_destroy);
....

This creates a problem.  There exist out-of-tree drivers which are
using those symbols and, even if sources are available, are not
licensed GPL for whatever reasons.  No, I am not the author of any
of those so I cannot do very much about re-licensing.  As an effect
a conversion to a "new driver model", even if simple, does not work.
In particular I bumped into that with Myrinet card drivers.

Was a decision to use EXPORT_SYMBOL_GPL deliberate and if yes then
what considerations dictated it, other then the patch author wrote
it that way, and what drivers in question are supposed to use when
this change will show up in the mainline?  It looks that 2.6.13
will do this.

  Thanks,
  Michal

Re: A "new driver model" and EXPORT_SYMBOL_GPL question

[Greg KH]

On Sun, Jul 03, 2005 at 05:12:02PM -0600, Michal Jaegermann wrote:
> It dawned on me only now that a "new driver model" introduced
> in patches from GKH export symbols like that:
> 
> EXPORT_SYMBOL_GPL(class_create);
> EXPORT_SYMBOL_GPL(class_destroy);
> 
> and so on.  The problem is that corresponding old symbols, which
> are still present in 2.6.12, were exported
> 
> EXPORT_SYMBOL(class_simple_create);
> EXPORT_SYMBOL(class_simple_destroy);
> ....
> 
> This creates a problem.  There exist out-of-tree drivers which are
> using those symbols

Where?  What drivers?

> and, even if sources are available, are not
> licensed GPL for whatever reasons.  No, I am not the author of any
> of those so I cannot do very much about re-licensing.  As an effect
> a conversion to a "new driver model", even if simple, does not work.
> In particular I bumped into that with Myrinet card drivers.

Then take it up with them.  Users of those symbols have had many months
advance notice that this was going to happen.

> Was a decision to use EXPORT_SYMBOL_GPL deliberate and if yes then
> what considerations dictated it, other then the patch author wrote
> it that way, and what drivers in question are supposed to use when
> this change will show up in the mainline?  It looks that 2.6.13
> will do this.

Please see the archives for the answers to these questions.

thanks,

greg k-h

Re: A "new driver model" and EXPORT_SYMBOL_GPL question

[Michal Jaegermann]

On Sun, Jul 03, 2005 at 10:44:41PM -0700, Greg KH wrote:
> On Sun, Jul 03, 2005 at 05:12:02PM -0600, Michal Jaegermann wrote:
> 
> > Was a decision to use EXPORT_SYMBOL_GPL deliberate and if yes then
> > what considerations dictated it, other then the patch author wrote
> > it that way, and what drivers in question are supposed to use when
> > this change will show up in the mainline?  It looks that 2.6.13
> > will do this.
> 
> Please see the archives for the answers to these questions.

I actually tried that before posting.  Maybe I attempted to look for
wrong things but, beyond conversion examples, I found some postings
with a general theme "there is no point to make life easy for
binary-only modules" and not much else.  I am afraid that this
leaves me not much wiser.

Also, at least when dealing with 2.6.13-r1, neither
Documentation/feature-removal-schedule.txt, nor files in
Documentation/driver-model/ directory, mention anything about a
switch to EXPORT_SYMBOL_GPL for relevant symbols.  The only thing I
can find about the later in "feature-removal..." is a note about RCU
API.

   Michal

Re: A "new driver model" and EXPORT_SYMBOL_GPL question

[Richard B. Johnson]

On Sun, 3 Jul 2005, Michal Jaegermann wrote:

> It dawned on me only now that a "new driver model" introduced
> in patches from GKH export symbols like that:
>
> EXPORT_SYMBOL_GPL(class_create);
> EXPORT_SYMBOL_GPL(class_destroy);
>
> and so on.  The problem is that corresponding old symbols, which
> are still present in 2.6.12, were exported
>
> EXPORT_SYMBOL(class_simple_create);
> EXPORT_SYMBOL(class_simple_destroy);
> ....
>
> This creates a problem.  There exist out-of-tree drivers which are
> using those symbols and, even if sources are available, are not
> licensed GPL for whatever reasons.  No, I am not the author of any
> of those so I cannot do very much about re-licensing.  As an effect
> a conversion to a "new driver model", even if simple, does not work.
> In particular I bumped into that with Myrinet card drivers.
>
> Was a decision to use EXPORT_SYMBOL_GPL deliberate and if yes then
> what considerations dictated it, other then the patch author wrote
> it that way, and what drivers in question are supposed to use when
> this change will show up in the mainline?  It looks that 2.6.13
> will do this.
>
>  Thanks,
>  Michal
> -

This problem will continue. Eventually there will be no general
exported symbols. The apparent idea is to prevent the use of the
kernel in proprietary systems.

Not to worry. The tools provided with a typical Linux distribution
are capable of resolving those symbols. You can make a script
that `greps`  System.map for the correct offsets of those symbols.
You can use those offsets in a linker script.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.12 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

Re: A "new driver model" and EXPORT_SYMBOL_GPL question

[Lars Marowsky-Bree]

On 2005-07-05T07:09:47, "Richard B. Johnson" <linux-os@analogic.com> wrote:

> This problem will continue. Eventually there will be no general
> exported symbols. The apparent idea is to prevent the use of the
> kernel in proprietary systems.

... with proprietary kernel extensions. There's a difference.

> Not to worry. The tools provided with a typical Linux distribution
> are capable of resolving those symbols. You can make a script
> that `greps`  System.map for the correct offsets of those symbols.
> You can use those offsets in a linker script.

If it wasn't you, I'd be assuming you'd be joking when suggesting to
subvert the clear wishes of and licensing granted by the copyright
holders and authors.



Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business	 -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"

Re: A "new driver model" and EXPORT_SYMBOL_GPL question

[Zan Lynx]

[-- Attachment #1: Type: text/plain, Size: 1521 bytes --]

On Sun, 2005-07-03 at 22:44 -0700, Greg KH wrote:
> On Sun, Jul 03, 2005 at 05:12:02PM -0600, Michal Jaegermann wrote:
[snip]
> Then take it up with them.  Users of those symbols have had many months
> advance notice that this was going to happen.
> 
> > Was a decision to use EXPORT_SYMBOL_GPL deliberate and if yes then
> > what considerations dictated it, other then the patch author wrote
> > it that way, and what drivers in question are supposed to use when
> > this change will show up in the mainline?  It looks that 2.6.13
> > will do this.
> 
> Please see the archives for the answers to these questions.

The archives say:
Greg KH wrote:
> 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

Sourced from here:
http://hulllug.principalhosting.net/archive/index.php/t-52440.html

That was the way it was as of 2.6.10-mm1 and it stayed that way through
2.6.12.  When did that decision change?  If it was there in the
archives, I missed it in the search.

If this was a Greg-only decision, perhaps a patch reversing the change
addressed to Linus would get a solid yes/no decision from the top.

From what I gather in the archives, the last time this happened it was
just a leak from Greg's tree and not an official policy change.  It
isn't in the feature removal schedule, even though other _GPL changes
are listed there.
-- 
Zan Lynx <zlynx@acm.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: A "new driver model" and EXPORT_SYMBOL_GPL question

[Greg KH]

On Tue, Jul 05, 2005 at 03:50:43PM -0600, Zan Lynx wrote:
> Sourced from here:
> http://hulllug.principalhosting.net/archive/index.php/t-52440.html

No, that is not the same topic or thread.

> That was the way it was as of 2.6.10-mm1 and it stayed that way through
> 2.6.12.  When did that decision change?  If it was there in the
> archives, I missed it in the search.

The code was totally rewritten from what was in 2.6.10-mm1, it was not
just a simple "license change".  All in-kernel users were converted, and
the known closed-source users of this code were also contacted and they
have already changed their code (nvidia being one of these users.)

If you know of any closed source code, using those functions, please put
them in contact with me.

> If this was a Greg-only decision, perhaps a patch reversing the change
> addressed to Linus would get a solid yes/no decision from the top.

What problem is this change causing you?  Do you have code that calls
these old, now gone, functions?

thanks,

greg k-h

Re: A "new driver model" and EXPORT_SYMBOL_GPL question

[Michal Jaegermann]

On Tue, Jul 05, 2005 at 02:57:40PM -0700, Greg KH wrote:
> On Tue, Jul 05, 2005 at 03:50:43PM -0600, Zan Lynx wrote:
> > Sourced from here:
> > http://hulllug.principalhosting.net/archive/index.php/t-52440.html
> 
> No, that is not the same topic or thread.

Formally you are correct but from my POV this sounds casuistic and
fit for a patent lawyer.  You were "recently advised not to change
these symbols" and you stated that you will not. So instead you did
an end run and you removed an old interface and introduced a
replacement; but this time with EXPORT_SYMBOL_GPL - which has the
same effect as what you told you will not do.

> If you know of any closed source code, using those functions, please put
> them in contact with me.

Well, I gave an example in my original question.  Yes, I asked them
to contact you.  If they will do that I have no idea.

   Michal

Re: A "new driver model" and EXPORT_SYMBOL_GPL question

[Greg KH]

On Tue, Jul 05, 2005 at 10:37:43PM -0600, Michal Jaegermann wrote:
> On Tue, Jul 05, 2005 at 02:57:40PM -0700, Greg KH wrote:
> > On Tue, Jul 05, 2005 at 03:50:43PM -0600, Zan Lynx wrote:
> > > Sourced from here:
> > > http://hulllug.principalhosting.net/archive/index.php/t-52440.html
> > 
> > No, that is not the same topic or thread.
> 
> Formally you are correct but from my POV this sounds casuistic and
> fit for a patent lawyer.

You must have have dealt with many patent lawyers.  I have, and they
operate in a league of their own on how to intrepret the english
language in patent claims :)

> You were "recently advised not to change
> these symbols" and you stated that you will not. So instead you did
> an end run and you removed an old interface and introduced a
> replacement; but this time with EXPORT_SYMBOL_GPL - which has the
> same effect as what you told you will not do.

I was "advised" to not do so, until the parties that were complaining
about the change, had time to convert their code.  They then did so, and
so, a number of MONTHS later, I did a rewrite of the code, which caused
me to create new functions and delete old, non-used functions.  Those
new functions were marked with the EXPORT_SYMBOL_GPL mark, as ALL of the
driver core functions are.  This change had lived in the -mm tree for a
number of months now, with no objections.

> > If you know of any closed source code, using those functions, please put
> > them in contact with me.
> 
> Well, I gave an example in my original question.  Yes, I asked them
> to contact you.  If they will do that I have no idea.

Thanks for doing so.

greg k-h