May be I can help to lower down the learning curve on this part a little bit: On Feb 3, 2008 10:57 AM, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote: > Hi all... > > On Feb 2, 2008 1:27 PM, Li Zefan <lizf@xxxxxxxxxxxxxx> wrote: > > No, the comment is correct. I just made a mistake... > > > > __initdata(and __devinidata etc..) can't be mixed with const, because otherwise > > the compiler will generate .init.data sections both with and without the > > writeable attribute. > > > > So we shoud use __devinitconst for const data. > > Thanks for the education, guys. So, basically, what I had said was > wrong? Did I understand correctly that once this happens: same section > name with different access attribute? > > regards, > > Mulyadi. > 1. what u said, is about correct. What happens is that GCC supports a "section" feature - take a look at "section" section at: http://gcc.gnu.org/onlinedocs/gcc-3.2.3/gcc/Variable-Attributes.html .2. so everywhere in the source, u see things like "__initdata" or __devinitdata or __cpuinitdata, which translates into gcc section ultimately after compilation. Their definition is in include/linux/init.h, and lots of __initdata internals are captured there - highly recommended read. The concept is that after the linux kernel initialized itself, many parts of the ELF in memory can be free up for other resources. THese are the so call __initdata (for .data) and __init (for .text) part of the ELF. So logically, u cannot call a __initdata or __init structure/function from a non-__init function, as it is not guaranteed to exist in memory. But vice versa is ok, and __init function can call __init function as well. This is exactly what modposting is doing. 3. After the ELF have been compiled with different section naming, forming the object module (*.o), it is then processed by modpost (located in scripts/mod/modpost.c) which basically parsed through the entire ELF and doing the symbol matching - exactly like what u said. The internal of modpost is in this file modpost.c (2000 lines code, no time to read). 4. Each kernel compilation takes about few hours, and at the end of it, is the modposting part, which I felt is just too time wasting. So I found a roundabout way to do this - much faster - in minutes. Take any source file, modify it, eg, removing or adding __devinitdata to it, then compile it via "make xxx.o" and then issue a ./scripts/mod/modpost xxx.o as the modpost commandline executeable takes in a ELF object as input. Of course, those inter-C files functions names cannot be matched - that is why modpost has to be done at the end, when all the object modules are available. As a future enhancement, it will help very much if the modposting can be broken up into two parts - those intra-C and inter-C files C functions, to save lots of time redoing the compilation. This is my personal understanding - may be in error - have not read much of it - just hacking..... Happy hacking! -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
