EXPORT_SYMBOL_GPL for __symbol_get replacing EXPORT_SYMBOL for deprecated inter_module_get

EXPORT_SYMBOL_GPL for __symbol_get replacing EXPORT_SYMBOL for deprecated inter_module_get

[Yuri Vilmanis]

I believe that, in general, new functions which replace deprecated functions 
which were exported as EXPORT_SYMBOL, should also be exported as 
EXPORT_SYMBOL, not as EXPORT_SYMBOL_GPL. The reason I say this is because 
deprecation of old functions breaks old modules and drivers that use them, 
and changing the level of GPL strictness of the function prevents these old 
modules being updated and used with newer kernels.

The case in point for me is ATI's binary openGL accelerated drivers (fglrx) - 
these used inter_module_get() to communicate with the agp gart module, for 
obvious reasons - this AGP communication is essential to the functionality of 
the driver. No, I don't like ATI only having closed-source drivers any more 
than you, but given the extremely competetive nature of high end video card 
sales, I can see why they want to do it this way. The point is that now, as 
of 2.6.11-? or 2.6.12-? (not sure of the exact revision), the 
inter_module_get() functions has been removed, and the functionality can only 
be got (as far as I can tell) through use of the symbol_get() function. 

Am I take it to mean that no closed-source / binary-only driver may use AGP 
acceleration in the future, including ones that have in the past? Or if an 
alternate method of AGP accelerated access exists (I dont know the kernel 
well enough to know for sure), does this mean companies which have at least 
been respectful enough to have provided linux drivers must now rewrite them 
to use an entirely different methodology in their drivers, write entirely new 
agp drivers which will then probably also be closed-source, and are likely to 
cause further problems down the line, or GPL drivers which contain code 
important to the competetiveness of the company? I think this is not a good 
situation for linux users or hardware manufacturers, and indeed shows Linux 
itself in a bad light.

I respect and agree with the use of EXPORT_SYMBOL_GPL to maintain new 
*software* functionality added by kernel developers, but when this prevents 
propriatary drivers from using advanced *hardware* features of common 
hardware connectivity devices like an AGP port, its silliness, plain and 
simple (I think this applies equally to other devices which are required for 
the connection of the device for which the propriatary driver was created, 
such as USB, PCI, serial, AGP, PCIExpress, firewire, IDA/SATA etcetc where 
DMA, ATA, fast serial (as provided by some Maxim chips with accelarated 
slew-rate) or other advanced advanced transfer modes are provided and enabled 
by the *harware*).

Also, deprecating non-GPL-strict functionality and replacing it with 
GPL-strict funtionality is just as bad, in my view, as going through the 
kernel and randomly changing instance of EXPORT_SYMBOL to EXPORT_SYMBOL_GPL - 
it has the same effect, of breaking established propriatary drivers, and 
forcing companies which do not feel that they can GPL the source and maintain 
their competetive advantage, to rewrite their drivers to use alternate 
methods (which they therefore have no certainty will be available in the 
future either), or dropping support altogether (which I'm sure nobody really 
wants). If Linux had a near-monopoly market share, it might be possible to 
get away with such strong-arm tactics in the interest of spreading the FSF 
distribution philosophy - but then again, look what similar tactics did to 
public opinion of the distribution philosophy of a certain Redmond company 
which did have near-monopoly market share.... I shudder at the thought of the 
point being applicable to Linux, but I think it must be made in order to 
prevent it becoming creepingly (and creepily) more valid in the future.

The case of inter_module_get deprecation and replacement with symbol_get 
embodies both sides: it makes a non-GPL export into a GPL export (yes, its 
now called by a different name, and the backend has changed, but the first 
change is cosmetic and the second change is internal), and it also prevents 
closed-source drivers from using functionality of a device that they have no 
choice but to connect through, and require for competetive performance.

To sum up:
1) Please make symbol_get a non-GPL export, so that those of us with hardware 
that needs it can continue to use it (eg anyone with an ATI video card that 
wants to use the shaders and extensions that are the point in favour over 
NVidia offerings)
2) I think the use of GPL symbol exports should be more carefully monitored 
where it affects existing closed-source drivers and designed-in hardware 
functionality like AGP, to avoid alienating companies which have been polite 
enough to come half way and supported their hardware under this great OS.

After all, I think we all want Linux to win by being the best - not by going 
around shouting "Thou shalt use the GPL, it ownz your propriatary 
distribution model and if you dont use it youre a moron and we wont let you 
use Linux" at passing strangers (not that this is likely to work anyway).

-Yuri

PS - This was not meant to be a rant, start a flamewar or even tread on 
anyones toes, really.... I'm just a bit annoyed that I can't do my shader 
development while running a nice bleeding-edge kernel, and apprehensive of 
not being able to do my shader development in a few months/years when this 
kernel is officially OldHat (TM, Inc, or whatever)

Re: EXPORT_SYMBOL_GPL for __symbol_get replacing EXPORT_SYMBOL for deprecated inter_module_get

[Arjan van de Ven]

On Wed, 2005-04-13 at 18:55 +0930, Yuri Vilmanis wrote:
> I believe that, in general, new functions which replace deprecated functions 
> which were exported as EXPORT_SYMBOL, should also be exported as 
> EXPORT_SYMBOL, not as EXPORT_SYMBOL_GPL. The reason I say this is because 
> deprecation of old functions breaks old modules and drivers that use them, 
> and changing the level of GPL strictness of the function prevents these old 
> modules being updated and used with newer kernels.
> 
> The case in point for me is ATI's binary openGL accelerated drivers (fglrx) - 
> these used inter_module_get() to communicate with the agp gart module, 

except that the AGP gart module no longer uses inter_module_*


> for 
> obvious reasons - this AGP communication is essential to the functionality of 
> the driver.

this is thus non-obvious..




> The case of inter_module_get deprecation and replacement with symbol_get 

inter_module_get is absolutely not replaced by symbol_get. They are
entirely different usages and only have a few letters in common in the
name.

Re: EXPORT_SYMBOL_GPL for __symbol_get replacing EXPORT_SYMBOL for deprecated inter_module_get

[Dave Airlie]

> The case in point for me is ATI's binary openGL accelerated drivers (fglrx) -
> these used inter_module_get() to communicate with the agp gart module, for
> obvious reasons - this AGP communication is essential to the functionality of
> the driver. No, I don't like ATI only having closed-source drivers any more
> than you, but given the extremely competetive nature of high end video card
> sales, I can see why they want to do it this way. The point is that now, as
> of 2.6.11-? or 2.6.12-? (not sure of the exact revision), the
> inter_module_get() functions has been removed, and the functionality can only
> be got (as far as I can tell) through use of the symbol_get() function.
> 

you might have done some research on what happened before ranting away
like a crazy.....

AGP dropped the drm_agp interface in favour of the DRM modules calling
the AGP backend directly, a patch for the ATI drivers has been sailing
around for ages I even wrote one myself for someone I think but I've
lost it now ... all the AGP symbols needed are exported with
EXPORT_SYMBOL.

you might have noticed no-one else complaining around here which is
usually a good sign that there is nothing worth complaining about :-)

Dave.

Re: EXPORT_SYMBOL_GPL for __symbol_get replacing EXPORT_SYMBOL for deprecated inter_module_get

[Dave Jones]

On Wed, Apr 13, 2005 at 06:55:00PM +0930, Yuri Vilmanis wrote:

 > The case in point for me is ATI's binary openGL accelerated drivers (fglrx) - 
 > these used inter_module_get() to communicate with the agp gart module, for 
 > obvious reasons - this AGP communication is essential to the functionality of 
 > the driver. No, I don't like ATI only having closed-source drivers any more 
 > than you, but given the extremely competetive nature of high end video card 
 > sales, I can see why they want to do it this way.
 > ....
 > Am I take it to mean that no closed-source / binary-only driver may use AGP 
 > acceleration in the future, including ones that have in the past?

They can use the in-kernel GART driver just fine. Of course, they choose
to take a bastardised version from some ancient tree, mangle it to
all hell, strip off the GPL MODULE_VERSION, and weld it to their
own driver, but that's their decision. Which is btw, whats partly
causing your problem.  (They still would've needed to change some
code, but the AGP side of the fence would be taken care of).

		Dave

Re: EXPORT_SYMBOL_GPL for __symbol_get replacing EXPORT_SYMBOL for deprecated inter_module_get

[Richard B. Johnson]

On Wed, 13 Apr 2005, Dave Jones wrote:

> On Wed, Apr 13, 2005 at 06:55:00PM +0930, Yuri Vilmanis wrote:
>
> > The case in point for me is ATI's binary openGL accelerated drivers (fglrx) -
> > these used inter_module_get() to communicate with the agp gart module, for
> > obvious reasons - this AGP communication is essential to the functionality of
> > the driver. No, I don't like ATI only having closed-source drivers any more
> > than you, but given the extremely competetive nature of high end video card
> > sales, I can see why they want to do it this way.
> > ....
> > Am I take it to mean that no closed-source / binary-only driver may use AGP
> > acceleration in the future, including ones that have in the past?
>
> They can use the in-kernel GART driver just fine. Of course, they choose
> to take a bastardised version from some ancient tree, mangle it to
> all hell, strip off the GPL MODULE_VERSION, and weld it to their
> own driver, but that's their decision. Which is btw, whats partly
> causing your problem.  (They still would've needed to change some
> code, but the AGP side of the fence would be taken care of).
>
> 		Dave

As a practical matter, one can make or modify the source-code
of a driver to use any symbols available in System.map. One
can even make a "preloader" program that gets the right stuff
for the correct kernel, puts it into the module, then has
the standard module loader load it.

There is way too much effort being applied to hiding kernel
symbols. As long as you have the tools available to build
a kernel, you have the tools available to use any symbol.

Here is the kernel offset of 'sys_call_table' and 'sys_ni_syscall'

TABLE := $(shell grep sys_call_table /boot/System.map | cut -f1 -d' ')
NISYS := $(shell grep sys_ni_syscall /boot/System.map | cut -f1 -d' ')
DEFS   = -D__KERNEL__ -DMODULE -DMAJOR_NR=$(MAJR) -DCONFIG_SMP
DEFS  += -DMODNAME=$(NAME) -DTABLE=0x$(TABLE) -DNISYS=0x$(NISYS)

You just initialize your module pointers to these values and
you have access to these objects. Simple.

Although I haven't tried it, I think one can even borrow a
__mod_licensexxx by using /proc/kallsyms. The point being that
trying to prevent one from using existing kernel code in
kernel modules will, eventually, fail completely unless we
only get binaries with no source-code. Even in that case,
many symbols within /proc/kallsyms are useful.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 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: EXPORT_SYMBOL_GPL for __symbol_get replacing EXPORT_SYMBOL for deprecated inter_module_get

[Sean]

On Wed, April 13, 2005 11:57 am, Richard B. Johnson said:
> On Wed, 13 Apr 2005, Dave Jones wrote:
>
>> On Wed, Apr 13, 2005 at 06:55:00PM +0930, Yuri Vilmanis wrote:
>>
>> > The case in point for me is ATI's binary openGL accelerated drivers
>> (fglrx) -
>> > these used inter_module_get() to communicate with the agp gart module,
>> for
>> > obvious reasons - this AGP communication is essential to the
>> functionality of
>> > the driver. No, I don't like ATI only having closed-source drivers any
>> more
>> > than you, but given the extremely competetive nature of high end video
>> card
>> > sales, I can see why they want to do it this way.
>> > ....
>> > Am I take it to mean that no closed-source / binary-only driver may
>> use AGP
>> > acceleration in the future, including ones that have in the past?
>>
>> They can use the in-kernel GART driver just fine. Of course, they choose
>> to take a bastardised version from some ancient tree, mangle it to
>> all hell, strip off the GPL MODULE_VERSION, and weld it to their
>> own driver, but that's their decision. Which is btw, whats partly
>> causing your problem.  (They still would've needed to change some
>> code, but the AGP side of the fence would be taken care of).
>>
>> 		Dave
>
> As a practical matter, one can make or modify the source-code
> of a driver to use any symbols available in System.map. One
> can even make a "preloader" program that gets the right stuff
> for the correct kernel, puts it into the module, then has
> the standard module loader load it.
>
> There is way too much effort being applied to hiding kernel
> symbols. As long as you have the tools available to build
> a kernel, you have the tools available to use any symbol.
>
> Here is the kernel offset of 'sys_call_table' and 'sys_ni_syscall'
>
> TABLE := $(shell grep sys_call_table /boot/System.map | cut -f1 -d' ')
> NISYS := $(shell grep sys_ni_syscall /boot/System.map | cut -f1 -d' ')
> DEFS   = -D__KERNEL__ -DMODULE -DMAJOR_NR=$(MAJR) -DCONFIG_SMP
> DEFS  += -DMODNAME=$(NAME) -DTABLE=0x$(TABLE) -DNISYS=0x$(NISYS)
>
> You just initialize your module pointers to these values and
> you have access to these objects. Simple.
>
> Although I haven't tried it, I think one can even borrow a
> __mod_licensexxx by using /proc/kallsyms. The point being that
> trying to prevent one from using existing kernel code in
> kernel modules will, eventually, fail completely unless we
> only get binaries with no source-code. Even in that case,
> many symbols within /proc/kallsyms are useful.
>

Yeah yeah.. yet another brilliant idea from the peanut gallery.   GPL_
symbols aren't meant to be some amazing protection from criminals that
don't care about licenses.   Hell, people pirate none GPL software too.  
The symbols are meant to help HONEST people comply with the license.

Please for gods sake, shut up.
Sean