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
33 matches
Mail list logo
