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
> 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
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
> 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
>
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.
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.
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
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.
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
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
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
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
[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
[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
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 registration
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
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
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 others
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
[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
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
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 another module
[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
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
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
> 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
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
> 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
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
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
> 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
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,
[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 */
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
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
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,
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
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?
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"
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 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 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
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 _must_
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 name is
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 each
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 _fixed_ and not
[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 */
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,
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 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/unload in
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
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 satisfied,
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
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
57 matches
Mail list logo
