Re: Suggestion for module .init.{text,data} sections
Hi!
> > A while ago, on linux-kernel, we had a discussion about
> > adding support for __initdata and __init in modules. Somebody
> > (whose name escapes me) had implemented it by essentially adding
> > a vmrealloc() facility in the kernel. I think I've thought of a
> > simpler way, that would require almost no kernel changes.
> >
> [implementation details snipped]
>
> While you are at this, you could make the .exit.{text,data}
> sections swappable for modules (by allocating swappable pages fro
> them?) and only mark them unswappable, while the module is
> exiting.
>
> Rationale: A device needed for swaping will never call exit
> stuff, because it is still in use. So I see no obvious race here.
You can't do that. Think about interrupt routine being swapped out.
Kernel is *not* preemptible.
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Suggestion for module .init.{text,data} sections
Hi!
A while ago, on linux-kernel, we had a discussion about
adding support for __initdata and __init in modules. Somebody
(whose name escapes me) had implemented it by essentially adding
a vmrealloc() facility in the kernel. I think I've thought of a
simpler way, that would require almost no kernel changes.
[implementation details snipped]
While you are at this, you could make the .exit.{text,data}
sections swappable for modules (by allocating swappable pages fro
them?) and only mark them unswappable, while the module is
exiting.
Rationale: A device needed for swaping will never call exit
stuff, because it is still in use. So I see no obvious race here.
You can't do that. Think about interrupt routine being swapped out.
Kernel is *not* preemptible.
--
Philips Velo 1: 1x4x8, 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Suggestion for module .init.{text,data} sections
Ingo Oeser wrote:
>
> On Thu, Apr 26, 2001 at 09:49:05PM -0700, Adam J. Richter wrote:
> > A while ago, on linux-kernel, we had a discussion about
> > adding support for __initdata and __init in modules. Somebody
> > (whose name escapes me) had implemented it by essentially adding
> > a vmrealloc() facility in the kernel. I think I've thought of a
> > simpler way, that would require almost no kernel changes.
> >
> [implementation details snipped]
>
> While you are at this, you could make the .exit.{text,data}
> sections swappable for modules (by allocating swappable pages fro
> them?) and only mark them unswappable, while the module is
> exiting.
>
> Rationale: A device needed for swaping will never call exit
> stuff, because it is still in use. So I see no obvious race here.
>
> Regards
__exit functions and data are usually too small to make the effort worth
it. __init functions and data on the other hand could be quite large,
if they contain firmware data for example.
--
Brian Gerst
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Suggestion for module .init.{text,data} sections
On Thu, Apr 26, 2001 at 09:49:05PM -0700, Adam J. Richter wrote:
> A while ago, on linux-kernel, we had a discussion about
> adding support for __initdata and __init in modules. Somebody
> (whose name escapes me) had implemented it by essentially adding
> a vmrealloc() facility in the kernel. I think I've thought of a
> simpler way, that would require almost no kernel changes.
>
[implementation details snipped]
While you are at this, you could make the .exit.{text,data}
sections swappable for modules (by allocating swappable pages fro
them?) and only mark them unswappable, while the module is
exiting.
Rationale: A device needed for swaping will never call exit
stuff, because it is still in use. So I see no obvious race here.
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag
been there and had much fun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Suggestion for module .init.{text,data} sections
On Thu, Apr 26, 2001 at 09:49:05PM -0700, Adam J. Richter wrote:
A while ago, on linux-kernel, we had a discussion about
adding support for __initdata and __init in modules. Somebody
(whose name escapes me) had implemented it by essentially adding
a vmrealloc() facility in the kernel. I think I've thought of a
simpler way, that would require almost no kernel changes.
[implementation details snipped]
While you are at this, you could make the .exit.{text,data}
sections swappable for modules (by allocating swappable pages fro
them?) and only mark them unswappable, while the module is
exiting.
Rationale: A device needed for swaping will never call exit
stuff, because it is still in use. So I see no obvious race here.
Regards
Ingo Oeser
--
10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag
been there and had much fun
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Suggestion for module .init.{text,data} sections
Ingo Oeser wrote:
On Thu, Apr 26, 2001 at 09:49:05PM -0700, Adam J. Richter wrote:
A while ago, on linux-kernel, we had a discussion about
adding support for __initdata and __init in modules. Somebody
(whose name escapes me) had implemented it by essentially adding
a vmrealloc() facility in the kernel. I think I've thought of a
simpler way, that would require almost no kernel changes.
[implementation details snipped]
While you are at this, you could make the .exit.{text,data}
sections swappable for modules (by allocating swappable pages fro
them?) and only mark them unswappable, while the module is
exiting.
Rationale: A device needed for swaping will never call exit
stuff, because it is still in use. So I see no obvious race here.
Regards
__exit functions and data are usually too small to make the effort worth
it. __init functions and data on the other hand could be quite large,
if they contain firmware data for example.
--
Brian Gerst
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Suggestion for module .init.{text,data} sections
A while ago, on linux-kernel, we had a discussion about adding support for __initdata and __init in modules. Somebody (whose name escapes me) had implemented it by essentially adding a vmrealloc() facility in the kernel. I think I've thought of a simpler way, that would require almost no kernel changes. Have insmod split the module into two parts and load them as two modules. First, create the regular part of the module as usual (without .data.init and .text.init), except with no initialization routine set. Second, create a module from the .data.init and the .text.init sections (if any), with it's initialization routine set to the module's init_module routine, even if that routine resides in the first module. Third, there will be cross references between these two modules, so will generally be necessary to resolve the relocations before loading either module. Fourth, load the first module. This will always succeed, since there is no initialization routine to fail. Fifth, load the second module, the one made of .data.init and .text.init. It will run the actual module_init function. If the module initialization routine fails, both modules are unloaded and the usual failure behavior happens. If the module initialization succeeds, the ".init" module (the second module) is unloaded. Potentially, this could save some memory footprint in highly modularized systems and cleanup linux/include/init.h. I guess I would imagine this as a potential 2.5 feature, or perhaps as a default-off option intended soley for stress testing in 2.4. I started looking through the modutils sources, but I was a little disappointed to discover that it is ELF-specific rather than written in bfd, as I am pretty unfamiliar with ELF innards but a little more conversant in bfd. Maybe I'll take a whack at it yet, but I figure I should at least pass the idea along and see if I'm overlooking anything obvious. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Suggestion for module .init.{text,data} sections
A while ago, on linux-kernel, we had a discussion about adding support for __initdata and __init in modules. Somebody (whose name escapes me) had implemented it by essentially adding a vmrealloc() facility in the kernel. I think I've thought of a simpler way, that would require almost no kernel changes. Have insmod split the module into two parts and load them as two modules. First, create the regular part of the module as usual (without .data.init and .text.init), except with no initialization routine set. Second, create a module from the .data.init and the .text.init sections (if any), with it's initialization routine set to the module's init_module routine, even if that routine resides in the first module. Third, there will be cross references between these two modules, so will generally be necessary to resolve the relocations before loading either module. Fourth, load the first module. This will always succeed, since there is no initialization routine to fail. Fifth, load the second module, the one made of .data.init and .text.init. It will run the actual module_init function. If the module initialization routine fails, both modules are unloaded and the usual failure behavior happens. If the module initialization succeeds, the .init module (the second module) is unloaded. Potentially, this could save some memory footprint in highly modularized systems and cleanup linux/include/init.h. I guess I would imagine this as a potential 2.5 feature, or perhaps as a default-off option intended soley for stress testing in 2.4. I started looking through the modutils sources, but I was a little disappointed to discover that it is ELF-specific rather than written in bfd, as I am pretty unfamiliar with ELF innards but a little more conversant in bfd. Maybe I'll take a whack at it yet, but I figure I should at least pass the idea along and see if I'm overlooking anything obvious. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 Free Software For The Rest Of Us. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
