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 <rpjday@xxxxxxxxxxxxxx> wrote: > On Sat, 15 Mar 2008, Peter Teoh wrote: > > > Hi Thomas Petazzoni, > > > > On Fri, Mar 14, 2008 at 10:06 PM, Peter Teoh <htmldeveloper@xxxxxxxxx> 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 ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ