inter_module_get and __symbol_get

inter_module_get and __symbol_get

[Terence Ripperda]

Hello,

we've noticed that in recent 2.6.10 kernels that the inter_module_
routines (such as inter_module_get) are marked deprecated. it appears
that the __symbol_ routines (such as __symbol_get) are intended as the
replacement routines.

unfortunately, __symbol_get is only exported as a GPL symbol (I see a
reference to a _gpl verion in module.h, but no definition). is this
intentional? will there be a non-gpled version of an equivalent
routine?

Thanks,
Terence

Re: inter_module_get and __symbol_get

[Brian Gerst]

Terence Ripperda wrote:
> Hello,
> 
> we've noticed that in recent 2.6.10 kernels that the inter_module_
> routines (such as inter_module_get) are marked deprecated. it appears
> that the __symbol_ routines (such as __symbol_get) are intended as the
> replacement routines.
> 
> unfortunately, __symbol_get is only exported as a GPL symbol (I see a
> reference to a _gpl verion in module.h, but no definition). is this
> intentional? will there be a non-gpled version of an equivalent
> routine?
> 
> Thanks,
> Terence

I believe there is an AGP/DRM rewrite in progress that should eliminate 
the need to use inter_module or symbol_get stuff.

--
				Brian Gerst

Re: inter_module_get and __symbol_get

[Terence Ripperda]

we currently use inter_module_get_request to make sure the agpgart
module is loaded when we initialize. does this mean we would no longer
need to make sure agpgart is loaded, or that it would always be
loaded?

Thanks,
Terence

On Thu, Jan 06, 2005 at 04:57:57PM -0500, bgerst@didntduck.org wrote:
> I believe there is an AGP/DRM rewrite in progress that should eliminate 
> the need to use inter_module or symbol_get stuff.
> 
> --
> 				Brian Gerst

Re: inter_module_get and __symbol_get

[Keith Owens]

On Thu, 06 Jan 2005 16:57:57 -0500, 
Brian Gerst <bgerst@didntduck.org> wrote:
>Terence Ripperda wrote:
>> Hello,
>> 
>> we've noticed that in recent 2.6.10 kernels that the inter_module_
>> routines (such as inter_module_get) are marked deprecated. it appears
>> that the __symbol_ routines (such as __symbol_get) are intended as the
>> replacement routines.
>> 
>> unfortunately, __symbol_get is only exported as a GPL symbol (I see a
>> reference to a _gpl verion in module.h, but no definition). is this
>> intentional? will there be a non-gpled version of an equivalent
>> routine?
>> 
>> Thanks,
>> Terence
>
>I believe there is an AGP/DRM rewrite in progress that should eliminate 
>the need to use inter_module or symbol_get stuff.

inter_module_* and the replacement __symbol_* routines are designed to
solve a generic problem, they are not only there for AGP/DRM.  I am
against removing these functions just because AGP/DRM no longer require
the facility, other code can hit the same generic problem.

inter_module_* and __symbol_* solve these class of problems:

Module A can use module B if B is loaded, but A does not require module
B to do its work.  B is optional.

The kernel can use code in module C is C is loaded, but the base kernel
does not require module C.  C is optional.

The standard module loader already handles the "require" cases, via the
unresolved symbol list and modules.dep.  The module loader cannot
handle the "optional" cases, because only the consumer of the optional
resources knows what it needs and what to do if the optional resources
are not available.  The consumer uses inter_module_* or __symbol_* to
detect and lock down the optional facilities.

Re: inter_module_get and __symbol_get

[Jon Smirl]

The inter_module_xxx free DRM is already in Linus BK. Sooner or later
the inter_module_xx exports in the AGP driver should disappear too.

DRM now handles things at compile time. If AGP is enabled at compile
time, AGP support gets built into the DRM module. If AGP is not
enabled, AGP does not get compiled in. If you try to take a DRM that
was built for AGP and move it to a system without, it's not going to
load because it will need the AGP symbols.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: inter_module_get and __symbol_get

[Terence Ripperda]

it would seem like the old mechanism was preferable, but perhaps I'm
missing something. in this particular case, there are times when a user
wants to avoid using agp at all for testing purposes, but if I
understand correctly, we'll be forced to load agpgart anyways due to
unresolved symbols.

but I think Keith Owens was correct in his larger picture view that
this mechanism is useful for much more than just agp. I'm just
confused why it was regressed from a non-gpl symbol to a gpl symbol
(or more appropriately why the non-gpl symbol was regressed in favor
of a gpl-only symbol).

Thanks,
Terence


On Fri, Jan 07, 2005 at 11:00:09PM -0500, jonsmirl@gmail.com wrote:
> The inter_module_xxx free DRM is already in Linus BK. Sooner or later
> the inter_module_xx exports in the AGP driver should disappear too.
> 
> DRM now handles things at compile time. If AGP is enabled at compile
> time, AGP support gets built into the DRM module. If AGP is not
> enabled, AGP does not get compiled in. If you try to take a DRM that
> was built for AGP and move it to a system without, it's not going to
> load because it will need the AGP symbols.
> 
> -- 
> Jon Smirl
> jonsmirl@gmail.com

Re: inter_module_get and __symbol_get

[Brian Gerst]

Terence Ripperda wrote:
> it would seem like the old mechanism was preferable, but perhaps I'm
> missing something. in this particular case, there are times when a user
> wants to avoid using agp at all for testing purposes, but if I
> understand correctly, we'll be forced to load agpgart anyways due to
> unresolved symbols.

In 2.6, the "agpgart" module is just the core.  Without a gart driver 
loaded (via-agp for example), it does nothing.  If you really don't want 
to have the hard dependency on agpgart, make the code using it 
conditionally compile on CONFIG_AGP or something.

> but I think Keith Owens was correct in his larger picture view that
> this mechanism is useful for much more than just agp. I'm just
> confused why it was regressed from a non-gpl symbol to a gpl symbol
> (or more appropriately why the non-gpl symbol was regressed in favor
> of a gpl-only symbol).

symbol_get in it's current form is hard-coded to look for GPL symbols, 
hence it is exported GPL only.  I have a rough patch that will allow 
symbol_get to use the license status of its caller to determine which 
symbols it can find.  However this depends on whether or not 
symbol_get() is removed like some people want.

--
				Brian Gerst

Re: inter_module_get and __symbol_get

[David Mosberger]

Keith,

I didn't see any followup to your message.  My apologies if I missed
something.

You wrote:

 Keith> inter_module_* and __symbol_* solve these class of problems:

 Keith> Module A can use module B if B is loaded, but A does not
 Keith> require module B to do its work.  B is optional.

 Keith> The kernel can use code in module C is C is loaded, but the
 Keith> base kernel does not require module C.  C is optional.

Why isn't this handled via weak references?  If the reference comes
out as 0, you know the underlying module/facility isn't there and
proceed accordingly.

	--david

Re: inter_module_get and __symbol_get

[Keith Owens]

On Mon, 24 Jan 2005 14:36:10 -0800, 
David Mosberger <davidm@napali.hpl.hp.com> wrote:
>Keith,
>
>I didn't see any followup to your message.  My apologies if I missed
>something.
>
>You wrote:
>
> Keith> inter_module_* and __symbol_* solve these class of problems:
>
> Keith> Module A can use module B if B is loaded, but A does not
> Keith> require module B to do its work.  B is optional.
>
> Keith> The kernel can use code in module C is C is loaded, but the
> Keith> base kernel does not require module C.  C is optional.
>
>Why isn't this handled via weak references?  If the reference comes
>out as 0, you know the underlying module/facility isn't there and
>proceed accordingly.

Weak references are only done once, when the module is loaded.  We
already use weak references for static determination of symbol
availability.  inter_module_* and __symbol_* are aimed at the dynamic
reference problem, not static.

Module A can use module B if B is loaded, but A does not require module
B to do its work.  B can be loaded at any time, or even unloaded at any
time, although that is much rarer.  Dynamic references require a
register/unregister style interface, thus inter_module_* and
__symbol_*.

Does the kernel code really need optional dynamic references between
modules or kernel -> modules?  That depends on how people code their
modules.  If the rest of the kernel no longer needs dynamic symbol
reference then drop inter_module_* and __symbol_*.

Re: inter_module_get and __symbol_get

[David Mosberger]

>>>>> On Tue, 25 Jan 2005 09:44:18 +1100, Keith Owens <kaos@ocs.com.au> said:

  Keith> Does the kernel code really need optional dynamic references
  Keith> between modules or kernel -> modules?  That depends on how
  Keith> people code their modules.  If the rest of the kernel no
  Keith> longer needs dynamic symbol reference then drop
  Keith> inter_module_* and __symbol_*.

Well, the only place that I know of where I (have to) care about
inter_module*() is because of the DRM/AGP dependency.  I can't imagine
DRM being overly happy if an AGP device suddenly disappeared, so I
think static is fine (in fact, probably preferable).

Of course, the trick is how to pull the backwards compatibility off
giving that for the time being we're more or less stuck with Nvidia's
5336 release on ia64... ;-(

	--david

Re: inter_module_get and __symbol_get

[Keith Owens]

On Mon, 24 Jan 2005 14:52:06 -0800, 
David Mosberger <davidm@napali.hpl.hp.com> wrote:
>>>>>> On Tue, 25 Jan 2005 09:44:18 +1100, Keith Owens <kaos@ocs.com.au> said:
>
>  Keith> Does the kernel code really need optional dynamic references
>  Keith> between modules or kernel -> modules?  That depends on how
>  Keith> people code their modules.  If the rest of the kernel no
>  Keith> longer needs dynamic symbol reference then drop
>  Keith> inter_module_* and __symbol_*.
>
>Well, the only place that I know of where I (have to) care about
>inter_module*() is because of the DRM/AGP dependency.  I can't imagine
>DRM being overly happy if an AGP device suddenly disappeared, so I
>think static is fine (in fact, probably preferable).

Does DRM support this model?

* Start DRM without AGP.
* AGP is loaded.
* DRM continues but now using AGP.

If yes then it needs dynamic symbol resolution.

Re: inter_module_get and __symbol_get

[David Mosberger]

>>>>> On Tue, 25 Jan 2005 09:54:36 +1100, Keith Owens <kaos@ocs.com.au> said:

  Keith> Does DRM support this model?

  Keith> * Start DRM without AGP.
  Keith> * AGP is loaded.
  Keith> * DRM continues but now using AGP.

  Keith> If yes then it needs dynamic symbol resolution.

I think it does, but I don't see any advantages to it (not on the
machines I'm using, at least).  In fact, I'd rather have an explicit
dependency on AGP.

	--david

Re: inter_module_get and __symbol_get

[Keith Owens]

On Mon, 24 Jan 2005 14:58:29 -0800, 
David Mosberger <davidm@napali.hpl.hp.com> wrote:
>>>>>> On Tue, 25 Jan 2005 09:54:36 +1100, Keith Owens <kaos@ocs.com.au> said:
>
>  Keith> Does DRM support this model?
>
>  Keith> * Start DRM without AGP.
>  Keith> * AGP is loaded.
>  Keith> * DRM continues but now using AGP.
>
>  Keith> If yes then it needs dynamic symbol resolution.
>
>I think it does, but I don't see any advantages to it (not on the
>machines I'm using, at least).  In fact, I'd rather have an explicit
>dependency on AGP.

No argument from me :).  I have always hated the dynamic resolution
model used by DRM/AGP and (originally) MTD.

I have a very dim and distant memory from about 6 years ago that
somebody wanted the ability to run DRM with and without AGP support.
IOW, the decision about whether to load AGP or not was left to the
user, instead of AGP always being automatically loaded by modprobe.
Again this comes down to static vs. dynamic symbol resolution.

Re: inter_module_get and __symbol_get

[Jon Smirl]

On Mon, 24 Jan 2005 14:52:06 -0800, David Mosberger
<davidm@napali.hpl.hp.com> wrote:
> Well, the only place that I know of where I (have to) care about
> inter_module*() is because of the DRM/AGP dependency.  I can't imagine

The DRM inter_module_XX dependency has been removed in 2.6.10. AGP
still exports inter_module_XX so that things like Nvidia/ATI drivers
will continue to work.

The last big use of inter_module_xx is in drivers/mtd in the M-systems
disk on a chip drivers.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: inter_module_get and __symbol_get

[David Mosberger]

>>>>> On Mon, 24 Jan 2005 18:19:05 -0500, Jon Smirl <jonsmirl@gmail.com> said:

  Jon> On Mon, 24 Jan 2005 14:52:06 -0800, David Mosberger
  Jon> <davidm@napali.hpl.hp.com> wrote:
  >> Well, the only place that I know of where I (have to) care about
  >> inter_module*() is because of the DRM/AGP dependency.  I can't
  >> imagine

  Jon> The DRM inter_module_XX dependency has been removed in
  Jon> 2.6.10. AGP still exports inter_module_XX so that things like
  Jon> Nvidia/ATI drivers will continue to work.

Not anymore:

  http://linux.bkbits.net:8080/linux-2.5/cset@41ef3420VDdf4OFNUTaC9jUaz8gR1A

	--david

Re: inter_module_get and __symbol_get

[Jon Smirl]

On Tue, 25 Jan 2005 10:03:01 +1100, Keith Owens <kaos@ocs.com.au> wrote:
> On Mon, 24 Jan 2005 14:58:29 -0800,
> David Mosberger <davidm@napali.hpl.hp.com> wrote:
> >>>>>> On Tue, 25 Jan 2005 09:54:36 +1100, Keith Owens <kaos@ocs.com.au> said:
> >
> >  Keith> Does DRM support this model?

DRM will compile two different modules depending of the state of
CONFIG_AGP. A module compiled for a system with AGP will not load into
one without it.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: inter_module_get and __symbol_get

[Terence Ripperda]

On Tue, Jan 25, 2005 at 09:44:18AM +1100, kaos@ocs.com.au wrote:
> Weak references are only done once, when the module is loaded.  We
> already use weak references for static determination of symbol
> availability.  inter_module_* and __symbol_* are aimed at the dynamic
> reference problem, not static.

this is probably a stupid question, but how are weak references used?
Usually if a symbol is referenced by a module, but isn't resolved at
load time, the module refuses to load. dynamic references allow a way
to work around this for some applications, but I'm unfamiliar with
weak references being used in this regard.

or does that statement really mean "if we supported weak references,
they would only be done once..."

Thanks,
Terence 

Re: inter_module_get and __symbol_get

[Chris Wedgwood]

On Mon, Jan 24, 2005 at 11:31:04PM -0600, Terence Ripperda wrote:

> this is probably a stupid question, but how are weak references
> used?

the linker sets them to zero, so "if (foo) { ... }" works nicely

it does mean if a module that set foo to non-zero is loaded, we need
to zero it again when it's unloaded or else we have stale bogus
pointers left around

Re: inter_module_get and __symbol_get

[D. ShadowWolf]

On this topic I have to weigh in that I just subscribed to the kernel list 
because I have had to undo a modification made to the kernel around version 
2.6.10 that stopped the export of 'inter_module_get'.  To me it appears that 
some kernel developers forget that there are those of us out there who do not 
have broadband connections and are shafted with low-end hardware. In this 
case I am currently stuck using a Lucent Winmodem to connect to the internet.
The need to undo that patch arose when I upgraded to 2.6.12.3 and found that 
the drivers provided by the linmodem project were dependant on that function. 
If the new system has been targeted at only GPL symbols, then I am certain it 
is definately not something good for the kernel.

I enjoy GPL'd software as much as the next guy, but forgetting that there are 
people in the world dependant on third-party drivers that may or may not have 
a non-GPL license attached to them shows short-sightedness on the part of the 
people involved. 

I have my own issues with the modem I'm currently using, and with the fact 
that Lucent sits behind a wall of NDA's and other legal documents and refuses 
to release the entire source of the driver, instead making us rely on a 
driver that has a precompiled binary as part of it's source. I'm certain 
there are people that could reverse engineer the binary (I could do it 
myself), but with the current state of the law in the US and abroad doing so 
could  cause major legal troubles.

Well... enough rambling. I've used too much bandwidth as it is.

DRH

Re: inter_module_get and __symbol_get

[Alan Cox]

On Sul, 2005-07-31 at 00:27 -0400, D. ShadowWolf wrote:
> On this topic I have to weigh in that I just subscribed to the kernel list 
> because I have had to undo a modification made to the kernel around version 
> 2.6.10 that stopped the export of 'inter_module_get'.  To me it appears that 
> some kernel developers forget that there are those of us out there who do not 
> have broadband connections and are shafted with low-end hardware.

inter_module_* are going away. It was always a badly designed interface
and the new module code no longer requires it. 

Alan