Thanks, i think I have found the answer......from a remote far away
directory - init.
On Sat, Mar 15, 2008 at 11:13 PM, Robert P. J. Day
<[EMAIL PROTECTED]> wrote:
> On Sat, 15 Mar 2008, Peter Teoh wrote:
>
> > Hi Thomas Petazzoni,
> >
> > On Fri, Mar 14, 2008 at 10:06 PM, Peter Teoh <[EMAIL PROTECTED]> wrote:
> > > >
> > > > The tag __initdata is for data used only during initialization (the
> > > > data is put in a special ELF section that is discarded after
> > > > initialization).
> > > >
> > > >
> > >
> > > When is the discarding taking place? Which part of the kernel
> > > source code is doing the discarding?
> > >
> > Just would like ask again does anyone know when is the memory
> > discarding (of the ELF section marked as __initdata) taking place?
>
> the ELF section is actually named ".init.data", i think, not
> "__initdata". anything tagged as __initdata is *placed* in the
> .init.data section.
>
>
> > first, the memory freeing must be triggered only after the __initdata
> > functions have been executed - how does the kernel knows that?
>
> i'm assuming you meant "after the **__init** functions have been
> executed", right?
>
>
> > next, this memory freeing MAY be executed while the module is still
> > loaded - so someone has to trigger the operation some where. when
> > and where -> within the kernel source code -- are these found?
>
> i believe all of that is done in the module loader code in
> kernel/module.c. specifically this section:
>
> DEBUGP("Core section allocation order:\n");
> for (m = 0; m < ARRAY_SIZE(masks); ++m) {
> for (i = 0; i < hdr->e_shnum; ++i) {
> Elf_Shdr *s = &sechdrs[i];
>
> if ((s->sh_flags & masks[m][0]) != masks[m][0]
> || (s->sh_flags & masks[m][1])
> || s->sh_entsize != ~0UL
> || strncmp(secstrings + s->sh_name,
> ".init", 5) == 0) <------
> continue;
> s->sh_entsize = get_offset(&mod->core_size, s);
> DEBUGP("\t%s\n", secstrings + s->sh_name);
> }
> if (m == 0)
> mod->core_text_size = mod->core_size;
>
Er...I don't think so either, as is nothing being freed here. just
chnaging some variables.
But I think I have found the answer:
init/main.c: kernel_init():
/*
* Ok, we have completed the initial bootup, and
* we're essentially up and running. Get rid of the
* initmem segments and start the user-mode stuff..
*/
init_post();
And in init_post():
/* This is a non __init function. Force it to be noinline otherwise gcc
* makes it inline to init() and it becomes part of init.text section
*/
static int noinline init_post(void)
{
free_initmem();
unlock_kernel();
mark_rodata_ro();
system_state = SYSTEM_RUNNING;
numa_default_policy();
if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
printk(KERN_WARNING "Warning: unable to open an
initial console.\n");
(void) sys_dup(0);
(void) sys_dup(0);
if (ramdisk_execute_command) {
run_init_process(ramdisk_execute_command);
printk(KERN_WARNING "Failed to execute %s\n",
ramdisk_execute_command);
}
/*
* We try each of these until one succeeds.
*
* The Bourne shell can be used instead of init if we are
* trying to recover a really broken machine.
*/
if (execute_command) {
run_init_process(execute_command);
printk(KERN_WARNING "Failed to execute %s. Attempting "
"defaults...\n", execute_command);
}
Thank you nevertheless to all who answered me, privately as well :-).
>
> and a very similar chunk of code immediately after that. i haven't
> looked at it carefully, but it certainly seems that any section whose
> name starts with ".init" is being bypassed for normal processing.
>
> rday
>
> p.s. what is the difference between those two code chunks? the first
> refers to "Core section allocation order" while the second is "Init
> section allocation order". can someone explain that so i can be lazy
> and not have to read it myself?
>
i really don't understand what the two chunk is doing either .....???
--
Regards,
Peter Teoh
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to [EMAIL PROTECTED]
Please read the FAQ at http://kernelnewbies.org/FAQ
