GreyZhang/g_unix: some basic learning about unix operating system. (github.com)
这是mmu.h的一部分，从这里其实能够看到一个转换的概念，那就是如何从线性地址转换到物理地址。从上面的注释其实能够看出一个比较清晰的三段结构，那就是页目录索引、页面索引、页偏移量。这三段信息分别占用了10bit、10bit、12bit。这里给出来的页地址处理则是上面三个信息进行组合的过程，这个组合其实是形成了线性地址的原始值。
这里看了一下上面的每一个操作的具体实现，从这些实现只能够看到三段信息与线性地址的关系。如果从x86的分页管理模型的角度考虑，其实现在还没有跟最终的物理地址产生什么关系。
感觉这一段的配置信息有一些难理解，可能得结合硬件说明的文档。不过这里的注释说明讲得还是很准确，有这里的这些信息可以进行一个推测以弄清楚这个映射机制。
按照上面的注释说明，为什么用+来增加一个flag其实是很清楚的，这个主要是用来实现编译的过程中就能够处理掉的初始化。如果，程序完成编译，这一段程序被链接器分配到KERNBASE + 1MB开始的位置。也就是，0xF0100000开始的位置。因此，这里涉及到的两个表的定义信息也基本上是在这个地址附近左右。如果，进行了一个减去KERNBASE的处理，其实里面的信息也就是在1MB这个地址附近，确切说是这个地址稍微往后一点的地方。这么看，在数值上entry_pgdir的第0个元素的数值应该是entry_pgtable数组在被BootLoader加载到物理存储之后的位置的一个字节之后的地址值。而这里面的第0x3c0个元素的数值则是比上面的数值再大2的一个数值。
如果靠猜测，接下来的处理逻辑很明确了。上面的四个参数，如何凑出来一个至少看着是4MB的信息组合。看起来，应该是需要研究下页表的定义信息才行。在存储的处理上，最小的单位是4K，因此如果是能够凑出来1M，其实是1K个page。
通过看这个表，其实可以看到一个基本的处理信息。我们看到的4M，其实很容易从这个数组的内容覆盖上凑出来。那么，这个表的信息决定了使用的物理存储范围？如果是这样，这里的每一个index其实是决定了一个4K段的起始地址。那么，如果让[KERNBASE, KERNBASE+4MB)的信息与这个产生对应关系呢？
为了弄清楚这个存储的管理模式，还是去查了一些文档。首先，我前面理解这个处理过程的时候就犯了一个错误。我一直在尝试把这个数值跟寄存器的信息做一个对照，但是这个数据结构是有自己的定义的。而当前的代码中，使用的PS其实是4K的模式。
为了便于分析，我改了编译的链接选项直接生成了map文件。这样能够在map中看到上面的地址，不用直接做理论推导。这样，第一个元素其实是0x113001，低12bit除了P位全都是0。第二个被初始化的元素值，比这个数值多了一个bit位的置位，加了读写。0x113001中的0x113其实是页表地址。
这样，对这段代码重新理解应该能够得出这样的基本推理信息：页目录表的index其实是需要处理的线性地址的高10bit，根据这个信息，可以索引到一个信息。而这个索引到的信息，包含两部分信息。第一部分信息是页表的地址，第二部分则是操作的属性。因此，上面的两个处理其实一个是把地址0开始的一段空间映射到了0~4MB的空间区域。另一个则是把KERNBASE开始的一段存储空间映射到了0~4MB。这个理解其实很简单，但是的确是费了点周折。
配置生效的方式非常简单，就是把页目录表的地址加载到CR3寄存器。
这个处理在JOS的entry.S中是在上面的代码中体现的。
这样，关于整个entry.S的分析中的一个遗憾终于是补充上了。继续往下分析JOS的行为，看起来更加理顺一些了。
