<div dir="ltr">I`m still reading all the resources, but I found a few more. <div><br></div><div><a href="http://www.ualberta.ca/CNS/RESEARCH/LinuxClusters/mem.html" target="_blank">http://www.ualberta.ca/CNS/RESEARCH/LinuxClusters/mem.html</a><br>


</div><div><br></div><div><br></div><div>I didn`t find a few answers yet, but how a module is loaded ? </div><div>When you do a insmod the kernel take some pages and load all the module&#39;s sections to these pages ? </div>


<div>How this work  ? Where I can find more information about memory allocation for a new module. </div><div>If I don`t find, I will read the source code for that part, but I try to find a better way to learn. I know that source code is the best and updated, but takes more time too. </div>


<div><br></div><div><br></div><div>And when I do a int inside my module I suppose that my int will be inside that pages that kernel allocated for my new module. Right ?? </div><div>But if I do this inside kernel code ? It&#39;s compiler task do allocate this memory in sections ? How the kernel runs ? Like my module is driven by kernel, but how kernel driven it&#39;s self ???</div>


<div><br></div><div><br></div><div>Thanks</div><div><br></div><div><br></div><div><br></div><div class="gmail_extra"><br clear="all"><div><div dir="ltr"><div>--</div>Lucas Tanure <br><a href="tel:%2B55%20%2819%29%20988176559" value="+5519988176559" target="_blank">+55 (19) 988176559</a><br>

</div></div>

<br><br><div class="gmail_quote">On Tue, Aug 5, 2014 at 12:31 AM, Peter Teoh <span dir="ltr">&lt;<a href="mailto:htmldeveloper@gmail.com" target="_blank">htmldeveloper@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div dir="ltr">And Q2:<div><br></div><div>Just want to comment that the load address has to be fixed initially, because unlike normal ELF, after loading ELF, there is a relocation tasks done by the linker.   In vmlinuz we cannot have relocation, before executing the kernel is the BIOS / uboot / bootloader etc.   One possible answer.   Others:<br>



</div><div><br></div><div><div><a href="https://groups.google.com/forum/#!topic/comp.os.linux.embedded/0-SAzCqQKFM" target="_blank">https://groups.google.com/forum/#!topic/comp.os.linux.embedded/0-SAzCqQKFM</a><br></div>


</div><div><br></div>
<div>And perhaps some of the links below may help you:</div><div><br></div><div><a href="http://jianggmulab.blogspot.sg/2010_01_01_archive.html" target="_blank">http://jianggmulab.blogspot.sg/2010_01_01_archive.html</a><div>


<br></div><div>
<a href="http://stackoverflow.com/questions/5647279/why-does-the-module-start-from-address-0xbf000000" target="_blank">http://stackoverflow.com/questions/5647279/why-does-the-module-start-from-address-0xbf000000</a><br></div>


<div><br></div>
<div><a href="http://www.arm.linux.org.uk/developer/memory.txt" target="_blank">http://www.arm.linux.org.uk/developer/memory.txt</a><br></div><div><br></div><div><a href="http://en.wikipedia.org/wiki/High_memory" target="_blank">http://en.wikipedia.org/wiki/High_memory</a><br>



</div><div><br></div><div>bottomline: keep googling.</div></div><div><br></div><div>Q6 and 7 makes no sense to me....sorry.</div><div><br></div></div><div class="gmail_extra"><div><div><br><br><div class="gmail_quote">
On Mon, Aug 4, 2014 at 11:22 PM, Lucas Tanure <span dir="ltr">&lt;<a href="mailto:tanure@linux.com" target="_blank">tanure@linux.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks!<br>
<br>
A quick look in all of that show me that there a lot of information<br>
about how kernel manage memory.<br>
But, I will find the answer for question 2, 6 and 7 in it ?<br>
<br>
Thanks!<br>
<div>--<br>
Lucas Tanure<br>
<a href="tel:%2B55%20%2819%29%20988176559" value="+5519988176559" target="_blank">+55 (19) 988176559</a><br>
<br>
<br>
</div><div><div>On Sun, Aug 3, 2014 at 8:58 PM, Peter Teoh &lt;<a href="mailto:htmldeveloper@gmail.com" target="_blank">htmldeveloper@gmail.com</a>&gt; wrote:<br>
&gt; I like your curiosities and interests in Linux<br>
&gt; kernel.<a href="http://virtuallyhyper.com/2013/07/rhcsa-and-rhce-chapter-10-the-kernel/" target="_blank">http://virtuallyhyper.com/2013/07/rhcsa-and-rhce-chapter-10-the-kernel/</a><br>
&gt;<br>
&gt; Instead of answering one by one, I think I will just identify the knowledge<br>
&gt; you are lacking:<br>
&gt;<br>
&gt; Memory management (from both x86/intel and linux kernel perspective).<br>
&gt;<br>
&gt; There are many many resources out there for you in these area, eg:<br>
&gt;<br>
&gt; <a href="http://en.wikipedia.org/wiki/Page_table" target="_blank">http://en.wikipedia.org/wiki/Page_table</a><br>
&gt; <a href="http://en.wikipedia.org/wiki/X86-64" target="_blank">http://en.wikipedia.org/wiki/X86-64</a><br>
&gt;<br>
&gt; (both boring, but just understand it well enough)<br>
&gt;<br>
&gt; <a href="http://wiki.osdev.org/Paging" target="_blank">http://wiki.osdev.org/Paging</a>   (good explanation....understand it very very<br>
&gt; well).<br>
&gt;<br>
&gt; The ultimate classic ebook:<br>
&gt;<br>
&gt; <a href="https://www.kernel.org/doc/gorman/pdf/understand.pdf" target="_blank">https://www.kernel.org/doc/gorman/pdf/understand.pdf</a><br>
&gt;<br>
&gt; And this blog site has tons of good info on intel/memory etc:<br>
&gt;<br>
&gt; <a href="http://duartes.org/gustavo/blog/post/cpu-rings-privilege-and-protection/" target="_blank">http://duartes.org/gustavo/blog/post/cpu-rings-privilege-and-protection/</a><br>
&gt; <a href="http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory/" target="_blank">http://duartes.org/gustavo/blog/post/anatomy-of-a-program-in-memory/</a><br>
&gt;<br>
&gt; <a href="http://virtuallyhyper.com/2013/07/rhcsa-and-rhce-chapter-10-the-kernel/" target="_blank">http://virtuallyhyper.com/2013/07/rhcsa-and-rhce-chapter-10-the-kernel/</a><br>
&gt;<br>
&gt; <a href="http://www.cse.psu.edu/~anand/spring01/linux/memory.ppt" target="_blank">http://www.cse.psu.edu/~anand/spring01/linux/memory.ppt</a><br>
&gt;<br>
&gt; One more thing:<br>
&gt;<br>
&gt; &quot;readelf -S -W vmlinux&quot; shows u the sections and the address where the<br>
&gt; different sections are supposed to be loaded in memory.   If u replace the<br>
&gt; vmlinux with the kernel module, eg: ip_tables.ko, then it says:<br>
&gt;<br>
&gt; starting at offset 0x328c blah blah....<br>
&gt;<br>
&gt; so the loaded address is with respect to ZERO, but then the actual module<br>
&gt; address is:<br>
&gt;<br>
&gt; sudo cat /proc/modules |grep ip_table<br>
&gt;<br>
&gt; ip_tables 18106 1 iptable_filter, Live 0xf8bf5000<br>
&gt;<br>
&gt; So all the output from your readelf, just add 0xf8bf5000 to it and you will<br>
&gt; get the actual virtual address of that section IN MEMORY.<br>
&gt;<br>
&gt; Just only in memory.   In file, the file offset of the section is different.<br>
&gt; And many parts inside the ELF is also different from memory too:   you will<br>
&gt; need to add the virtual load address (above) to the offset as specified<br>
&gt; inside the relocation tables (objdump -r), and for each section there is a<br>
&gt; separate relocation table (all independent from another, meaning that the<br>
&gt; different section CAN BE loaded to different parts in memory).<br>
&gt;<br>
&gt; Thanks.<br>
&gt;<br>
&gt;<br>
&gt; On Sun, Aug 3, 2014 at 11:59 PM, Lucas Tanure &lt;<a href="mailto:tanure@linux.com" target="_blank">tanure@linux.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hi,<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m looking for some site, pdf, book etc, that can answer this questions.<br>
&gt;&gt; For now I have :<br>
&gt;&gt;<br>
&gt;&gt; <a href="http://unix.stackexchange.com/questions/5124/what-does-the-virtual-kernel-memory-layout-in-dmesg-imply" target="_blank">http://unix.stackexchange.com/questions/5124/what-does-the-virtual-kernel-memory-layout-in-dmesg-imply</a><br>




&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I want to understand a few things about the memory and the execution<br>
&gt;&gt; of Linux kernel.<br>
&gt;&gt; Taking from a X86 and grub I have:<br>
&gt;&gt;<br>
&gt;&gt; 1) Grub loads kernel and root file system in memory, and the vmlinux<br>
&gt;&gt; has the code to decompress it self, right ? linux<br>
&gt;&gt;<br>
&gt;&gt; 2) The address of load kernel is always the same ? And It&#39;s at<br>
&gt;&gt; compilation time that is chosen ?<br>
&gt;&gt;<br>
&gt;&gt; 2a) The kernel takes places in 3g-4g memory place, and user space from 0<br>
&gt;&gt; to 3gb.<br>
&gt;&gt; But if the pc has only 256mb of memory ?<br>
&gt;&gt; And when pc has 16gb of memory, the user space will be split in two ?<br>
&gt;&gt;<br>
&gt;&gt; 2b) And if kernel has soo many modules that needs more than 1gb to run ?<br>
&gt;&gt;<br>
&gt;&gt; 2c) How we configure all of that memory configs ? make menuconfig and<br>
&gt;&gt; friends ?<br>
&gt;&gt;<br>
&gt;&gt; 3) The function A will call functon B. B is at 0xGGGGGG in .text<br>
&gt;&gt; section, but kernel was loaded in address 0xJJJJJJJJJJ, how A will<br>
&gt;&gt; find B ?<br>
&gt;&gt;<br>
&gt;&gt; 4) Please consider this:<br>
&gt;&gt; $ readelf -S -W vmlinux<br>
&gt;&gt; There are 37 section headers, starting at offset 0xe05718:<br>
&gt;&gt;<br>
&gt;&gt; Section Headers:<br>
&gt;&gt;   [Nr] Name                           Type              Address<br>
&gt;&gt;                 Off             Size          ES Flg Lk Inf Al<br>
&gt;&gt;   [ 0]                                      NULL<br>
&gt;&gt; 0000000000000000    000000      000000     00      0   0  0<br>
&gt;&gt;   [ 1] .text                             PROGBITS<br>
&gt;&gt; ffffffff81000000          200000     53129a      00  AX  0   0 4096<br>
&gt;&gt;   [ 2] .notes                          NOTE<br>
&gt;&gt; ffffffff8153129c          73129c     0001d8      00  AX  0   0  4<br>
&gt;&gt;   [ 3] __ex_table                   PROGBITS        ffffffff81531480<br>
&gt;&gt;        731480     002018      00   A  0   0  8<br>
&gt;&gt;   [ 4] .rodata                         PROGBITS<br>
&gt;&gt; ffffffff81600000          800000     1655ee     00   A  0   0 64<br>
&gt;&gt;   [ 5] __bug_table                 PROGBITS        ffffffff817655f0<br>
&gt;&gt;        9655f0      005424     00   A  0   0  1<br>
&gt;&gt;   [ 6] .pci_fixup                     PROGBITS        ffffffff8176aa18<br>
&gt;&gt;          96aa18     002f88      00   A  0   0  8<br>
&gt;&gt;   [ 7] .tracedata                    PROGBITS        ffffffff8176d9a0<br>
&gt;&gt;         96d9a0     00003c     00   A  0   0  1<br>
&gt;&gt;   [ 8] __ksymtab                   PROGBITS        ffffffff8176d9e0<br>
&gt;&gt;       96d9e0     00e710     00   A  0   0 16<br>
&gt;&gt;   [ 9] __ksymtab_gpl             PROGBITS        ffffffff8177c0f0<br>
&gt;&gt;     97c0f0      00a150      00   A  0   0 16<br>
&gt;&gt;   [10] __kcrctab                     PROGBITS        ffffffff81786240<br>
&gt;&gt;        986240     007388     00   A  0   0  8<br>
&gt;&gt;   [11] __kcrctab_gpl              PROGBITS        ffffffff8178d5c8<br>
&gt;&gt;      98d5c8     0050a8     00   A  0   0  8<br>
&gt;&gt;   [12] __ksymtab_strings      PROGBITS        ffffffff81792670<br>
&gt;&gt;  992670     01cb42   00   A  0   0  1<br>
&gt;&gt;   [13] __init_rodata               PROGBITS        ffffffff817af1c0<br>
&gt;&gt;        9af1c0      0000e8   00   A  0   0 32<br>
&gt;&gt;   [14] __param                      PROGBITS        ffffffff817af2a8<br>
&gt;&gt;         9af2a8     000b00   00   A  0   0  8<br>
&gt;&gt;   [15] __modver                    PROGBITS        ffffffff817afda8<br>
&gt;&gt;        9afda8     000258   00   A  0   0  8<br>
&gt;&gt;   [16] .data                            PROGBITS<br>
&gt;&gt; ffffffff81800000          a00000     0e1180   00  WA  0   0 4096<br>
&gt;&gt;   [17] .vvar                            PROGBITS<br>
&gt;&gt; ffffffff818e2000          ae2000     001000   00  WA  0   0 16<br>
&gt;&gt;   [18] .data..percpu               PROGBITS        0000000000000000<br>
&gt;&gt; c00000     015300   00  WA  0   0 4096<br>
&gt;&gt;   [19] .init.text                       PROGBITS<br>
&gt;&gt; ffffffff818f9000           cf9000      0503ea   00  AX  0   0 16<br>
&gt;&gt;   [20] .init.data                      PROGBITS<br>
&gt;&gt; ffffffff8194a000           d4a000    09e4c8   00  WA  0   0 4096<br>
&gt;&gt;   [21] .x86_cpu_dev.init        PROGBITS        ffffffff819e84c8<br>
&gt;&gt;     de84c8    000018   00   A  0   0  8<br>
&gt;&gt;   [22] .parainstructions         PROGBITS        ffffffff819e84e0<br>
&gt;&gt;      de84e0    00bd3c   00   A  0   0  8<br>
&gt;&gt;   [23] .altinstructions            PROGBITS        ffffffff819f4220<br>
&gt;&gt;         df4220     005f40   00   A  0   0  1<br>
&gt;&gt;   [24] .altinstr_replacement  PROGBITS        ffffffff819fa160<br>
&gt;&gt;   dfa160     001a69   00  AX  0   0  1<br>
&gt;&gt;   [25] .iommu_table              PROGBITS        ffffffff819fbbd0<br>
&gt;&gt;      dfbbd0     0000f0   00   A  0   0  8<br>
&gt;&gt;   [26] .apicdrivers                 PROGBITS        ffffffff819fbcc0<br>
&gt;&gt;          dfbcc0     000020   00  WA  0   0  8<br>
&gt;&gt;   [27] .exit.text                     PROGBITS        ffffffff819fbce0<br>
&gt;&gt;            dfbce0     0009bc   00  AX  0   0  1<br>
&gt;&gt;   [28] .smp_locks                  PROGBITS        ffffffff819fd000<br>
&gt;&gt;         dfd000    005000   00   A  0   0  4<br>
&gt;&gt;   [29] .data_nosave              PROGBITS        ffffffff81a02000<br>
&gt;&gt;      e02000    001000   00  WA  0   0  4<br>
&gt;&gt;   [30] .bss                             NOBITS<br>
&gt;&gt; ffffffff81a03000            e03000    122000   00  WA  0   0 4096<br>
&gt;&gt;   [31] .brk                              NOBITS<br>
&gt;&gt; ffffffff81b25000           e03000    425000   00  WA  0   0  1<br>
&gt;&gt;   [32] .comment                   PROGBITS        0000000000000000<br>
&gt;&gt; e03000    000027   01  MS  0   0  1<br>
&gt;&gt;   [33] .debug_frame             PROGBITS        0000000000000000<br>
&gt;&gt; e03028    002560   00      0   0  8<br>
&gt;&gt;   [34] .shstrtab                     STRTAB<br>
&gt;&gt; 0000000000000000     e05588    00018a 00      0   0  1<br>
&gt;&gt;   [35] .symtab                      SYMTAB            0000000000000000<br>
&gt;&gt;     e06058    1a29f8 18     36 43659  8<br>
&gt;&gt;   [36] .strtab                         STRTAB<br>
&gt;&gt; 0000000000000000     fa8a50    180d92 00      0   0  1<br>
&gt;&gt; Key to Flags:<br>
&gt;&gt;   W (write), A (alloc), X (execute), M (merge), S (strings), l (large)<br>
&gt;&gt;   I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)<br>
&gt;&gt;   O (extra OS processing required) o (OS specific), p (processor specific)<br>
&gt;&gt;<br>
&gt;&gt; So the vmlinux is loaded in memory like a dd ?<br>
&gt;&gt;<br>
&gt;&gt; 5) In my function A, inside the module that I wrote, a non-initialized<br>
&gt;&gt; variable will take place in non-initialized section that was loaded in<br>
&gt;&gt; memory ?<br>
&gt;&gt; Or my modules has a new sections for it&#39;s own use, and my module is<br>
&gt;&gt; loaded my memory like a process, with all his sections?<br>
&gt;&gt; So how another module or kernel code will fin my exported<br>
&gt;&gt; variable/function ?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; 6) Let&#39;s suppose:<br>
&gt;&gt; I have a int variable, with 17 as content, and the address is 0xGGGGGG.<br>
&gt;&gt; If I stop the linux in this time, read my memory at address 0xGGGGGG I<br>
&gt;&gt; will got 17, right ?<br>
&gt;&gt; 0xGGGGGGG will be bigger than 0xc0000000 always,  right ?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; 7) Now take int from question and change for:<br>
&gt;&gt; struct mystruct * foo = (struct mystruct* ) kmalloc(sizeof(struct<br>
&gt;&gt; mystruct));<br>
&gt;&gt;<br>
&gt;&gt; I will be able to read at address 0xGGGGGG the struct that created,<br>
&gt;&gt; and it address will be greater than 0xc0000000, right ?<br>
&gt;&gt; But for this struct, the memory will be allocated for ever, until I<br>
&gt;&gt; free the pointer, right ?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Well, this just a start. I really want to understand how kernel is<br>
&gt;&gt; run, loaded etc. Any help is appreciate, answering my questions, links<br>
&gt;&gt; to read, books to read.<br>
&gt;&gt; Actually, I didn&#39;t find any book with that kind of information .<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Lucas Tanure<br>
&gt;&gt; <a href="tel:%2B55%20%2819%29%20988176559" value="+5519988176559" target="_blank">+55 (19) 988176559</a><br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; To unsubscribe, send a message with &#39;unsubscribe linux-mm&#39; in<br>
&gt;&gt; the body to <a href="mailto:majordomo@kvack.org" target="_blank">majordomo@kvack.org</a>.  For more info on Linux MM,<br>
&gt;&gt; see: <a href="http://www.linux-mm.org/" target="_blank">http://www.linux-mm.org/</a> .<br>
&gt;&gt; Don&#39;t email: &lt;a href=mailto:&quot;<a href="mailto:dont@kvack.org" target="_blank">dont@kvack.org</a>&quot;&gt; <a href="mailto:email@kvack.org" target="_blank">email@kvack.org</a> &lt;/a&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Regards,<br>
&gt; Peter Teoh<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br>Regards,<br>Peter Teoh
</font></span></div>
</blockquote></div><br></div></div>