On Sat, 28 Oct 2000 11:02:04 +0100 (BST),
Alan Cox <[EMAIL PROTECTED]> wrote:
>> of get_module_symbol this weekend. The inter-object registration code
>> will allow two objects to pass data to each other, it will not matter
>> whether the objects are both modules, one module and one built in (in
> Linus wants get_module_symbol removed.
> http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg08791.html
Looks to me like Linus asks if some stuff can go away. I don't see a Linus
comment on the rest of the discussion about why removing it is bad at all.
And by Linus own rules. Its too
> of get_module_symbol this weekend. The inter-object registration code
> will allow two objects to pass data to each other, it will not matter
> whether the objects are both modules, one module and one built in (in
> either order) or both built in. When modules are involved there will
> be full
On Sat, 28 Oct 2000 05:40:28 -0400 (EDT),
Alan Cox <[EMAIL PROTECTED]> wrote:
>> cc list trimmed. Nobody has come up with a "must have" reason for
>> get_module_symbol and that interface is broken as designed. I will be
>
>Nobody has come up with a 'must break existing sane code' reason either.
> cc list trimmed. Nobody has come up with a "must have" reason for
> get_module_symbol and that interface is broken as designed. I will be
Nobody has come up with a 'must break existing sane code' reason either.
> will allow two objects to pass data to each other, it will not matter
> whether
Keith Owens wrote:
>
> I will be adding generic inter-object registration code and removing
> all vestiges of get_module_symbol this weekend.
While you're there, why not eradicate sys_get_kernel_syms()?
Also, I've been sitting on (and using) this sys_init_init_module()
bugfix for two months.
On Fri, 27 Oct 2000 14:25:48 +0100,
David Woodhouse <[EMAIL PROTECTED]> wrote:
>But in the case where there _aren't_ any functions which could usefully be
>shared between the modules, you've got a whole extra gratuitous module
>(What's that, 32KiB on some ARM boxen?) just to hold the registrati
[EMAIL PROTECTED] said:
> > But that module then depends on both of the others unless you keep
> > recompiling it
> Not really, see for example ns558.c and adi.c plus their third module
> gameport.c, all in drivers/char/joystick.
But in the case where there _aren't_ any functions which could u
On Thu, Oct 26, 2000 at 06:21:41PM -0400, Alan Cox wrote:
> > Well, this is usually handled by a third module that takes care of
> > registering/unregistering the existence of the two modules that need to
> > be possible to load/unload separately.
>
> But that module then depends on both of the
> Well, this is usually handled by a third module that takes care of
> registering/unregistering the existence of the two modules that need to
> be possible to load/unload separately.
But that module then depends on both of the others unless you keep recompiling
it
-
To unsubscribe from this li
On Wed, Oct 18, 2000 at 02:25:41PM -0400, Rik Faith wrote:
> Just to clarify -- my use of get_module_symbol has nothing to do with
> load order. It has to do with allowing a drm module to work with or
> without the agpgart module loaded.
>
> If there's some other way to do this, I'll be happy to
[EMAIL PROTECTED] said:
> You need it to dynamically bind to another module if its loaded and
> still be loadable if that module/facility is not present. Its dynamic
> linking for kernel modules
However, in order for get_module_symbol() to be safe, it needs to
increase the use count of the m
On Wed, Oct 18, 2000 at 10:14:01PM +0100, Alan Cox wrote:
> > The only other users are 8390.h and a couple of mtd things. I don't see
> > why this stuff cannot be handled in userspace with /etc/modules.conf ...
> >
> > should get_module_symbol() die ?
>
> You need it to dynamically bind to anoth
On Thu, 19 Oct 2000 01:56:38 +0100 (BST),
Alan Cox <[EMAIL PROTECTED]> wrote:
>Keith Owens wrote
>> modprobe would attempt to satisfy weak external references as if they
>> were normal references, including all the module dependency chains and
>> reference counts. If the reference cannot be sati
> modprobe would attempt to satisfy weak external references as if they
> were normal references, including all the module dependency chains and
> reference counts. If the reference cannot be satisfied, it is set to
> zero instead of causing an error. No changes to load/unload.
I dont believe m
On Wed, 18 Oct 2000 20:44:19 -0400 (EDT),
Alan Cox <[EMAIL PROTECTED]> wrote:
>Keith Owens wrote
>> Nice and clean. WEAK_EXTERN does some magic to create a NULL pointer
>> at link time or load time if the symbol is not resolved.
>
>It also has to do the rest of the magic to handle module load/un
> Nice and clean. WEAK_EXTERN does some magic to create a NULL pointer
> at link time or load time if the symbol is not resolved.
It also has to do the rest of the magic to handle module load/unload in
parallel but that can be done as per the current code
> Linus, do you want a patch for this?
On Thu, 19 Oct 2000 01:46:26 +0200,
Jamie Lokier <[EMAIL PROTECTED]> wrote:
>John Levon wrote:
>> should get_module_symbol() die ?
>
>Please no. I use it for a situation where two drivers can be used
>independently. However, when they're loaded at the same time they
>communicate. Having a thir
John Levon wrote:
> should get_module_symbol() die ?
Please no. I use it for a situation where two drivers can be used
independently. However, when they're loaded at the same time they
communicate. Having a third module _just_ to work out how the devices
are related (based on PCI bus topology)
> The only other users are 8390.h and a couple of mtd things. I don't see
> why this stuff cannot be handled in userspace with /etc/modules.conf ...
>
> should get_module_symbol() die ?
You need it to dynamically bind to another module if its loaded and still be
loadable if that module/facility
[EMAIL PROTECTED] said:
> (So, yes, you can still customize a drm module for your specific
> kernel. But I'm arguing for the ability to build a generic drm module
> that will determine agpgart presence at run time and use it if
> needed.)
Definitely worthwhile. Just don't make anything in the
On Wed 18 Oct 2000 19:23:54 +0100,
David Woodhouse <[EMAIL PROTECTED]> wrote:
> Don't you need to deal with the !CONFIG_AGP case correctly?
This should already be dealt with in the Makefile -- if !CONFIG_AGP,
then the file that we've been talking about (agpsupport.c) isn't
compiled.
(So, yes,
[EMAIL PROTECTED] said:
> #ifdef CONFIG_MODULES
/* use get_module_symbol() */
> #else
/* reference agp_* directly */
> #endif
Don't you need to deal with the !CONFIG_AGP case correctly?
#ifdef CONFIG_MODULES
/* blah */
#elif CONFIG_AGP
/* blah */
a
On Wed 18 Oct 2000 10:49:24 -0700,
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 18 Oct 2000, Christoph Hellwig wrote:
>
> > In article <[EMAIL PROTECTED]> you
>wrote:
> >
> > > I have no idea what the get_module_symbol() code in question is trying to
> > > do, but this should be
On Wed, 18 Oct 2000, Rik Faith wrote:
> [Note that the other way to fix this would be to export
> get_module_symbol all the time, and have it just search the available
> symbol space if CONFIG_MODULES is 'n'.]
and
s/_module//;
it is mis-named already ...
john
--
"Mathemeticians stand on ea
On Wed 18 Oct 2000 09:43:43 -0700,
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 18 Oct 2000, John Levon wrote:
> >
> > I have only compile-tested the patch below with 2.4.0test10pre3 and
> > 2.2.18pre16 (some fuzz on apply). Hope it's right, I can't test if it
> > fixes the MODVER
On Wed, 18 Oct 2000, Christoph Hellwig wrote:
> In article <[EMAIL PROTECTED]> you
>wrote:
>
> > I have no idea what the get_module_symbol() code in question is trying to
> > do, but this should be _fixed_ and not just worked around. That's a bug.
>
> It gets the symbol of a function, that's
[EMAIL PROTECTED] said:
> The only other users are 8390.h and a couple of mtd things. I don't
> see why this stuff cannot be handled in userspace with /etc/
> modules.conf ...
Patch please :)
Either you'll see, or I'll owe you a beer. I'm happy either way.
> should get_module_symbol() die ?
In article <[EMAIL PROTECTED]> you wrote:
> However, the fact that you need that dependency on CONFIG_MODULES _still_
> shows that something is wrong. That dependency should not be there, and
> the drm code should be fixed. Why does it care about CONFIG_MODULES at
> all? It should not, and it _mu
On Wed, 18 Oct 2000, Linus Torvalds wrote:
> It looks better.
>
> However, the fact that you need that dependency on CONFIG_MODULES _still_
> shows that something is wrong. That dependency should not be there, and
> the drm code should be fixed. Why does it care about CONFIG_MODULES at
> all? It
On Wed, 18 Oct 2000, John Levon wrote:
>
> I have only compile-tested the patch below with 2.4.0test10pre3 and
> 2.2.18pre16 (some fuzz on apply). Hope it's right, I can't test if it
> fixes the MODVERSIONS+in kernel agp+in kernel drm case. I tested kernel
> and module cases.
It looks better.
On Tue, 17 Oct 2000, Linus Torvalds wrote:
> There's something else wrong in the config to make this be needed at all.
> You need to figure out what the real problem is, and what is causing the
> AGP symbols to not get version information. Probably a file is missing
> from the "export-objs" list.
On Tue, 17 Oct 2000, John Levon wrote:
>
> The patch below allows agpsupport to find the agp functions
> when modversions is set and both AGP and DRM are compiled into the kernel,
> and adds the dependency on CONFIG_MODULES explicitly.
There's something else wrong in the config to make this be
The patch below allows agpsupport to find the agp functions
when modversions is set and both AGP and DRM are compiled into the kernel,
and adds the dependency on CONFIG_MODULES explicitly.
It applies cleanly to both 2.4.0-test10pre3 and 2.2.18pre16, but only
tested on 2.4
thanks
john
--- drive
34 matches
Mail list logo