全部学习汇总： GreyZhang/g_unix: some basic learning about unix operating system. (github.com)

         继续尝试完善分析JOS的代码中存储管理的部分。

         上次看到了这里，本来想先去看看这两个函数实现。但是缺失了调用场景，感觉理解也不一定准确。干脆，还是继续向下看一下check_page_free_list(1)所实现的功能。

         这里涉及到一个新的函数接口，需要去看一下。

         这里，就得回顾一下pages是如何来的了。这个其实是在前面初始化的时候分配出来的一块存储，接着进行了页管理信息的初始化。初始化的过程中，把没有使用的存储全都关联到了一个链表之上。那么，这个函数实现的是按照页信息相对于pages的基地址的偏移来找到对应的物理地址，而这个跟真实的物理地址是一一对应的关系。也就是说，其实pages中的信息就是每4K物理存储会有一个元素作为其中的映射信息。由此，从上面的逻辑运算中，能够计算出来的其实是对应的页面管理信息所映射的物理存储的页开始地址。

         这一段逻辑的设计，开始看的时候有些费解。其实，整个过程也比较理顺，可以理解为按照地址的属性进行了分组。分组结束之后，page_free_list引用了低区的存储链表信息。

         最开始检查不应该在链表中存在的配置，检查的主要条件是看PDX。我觉得这个肯定是有很多在这个范围内的，这刚好是前面的一轮处理的结果。

         接下来的检查倒是比较容易让人理解，主要还是检查了一些存储的边界范围是否在合理的范围之内。

         我在软件中增加了几个测试接口，用来看软件执行到了什么位置。

         以上是执行效果，从这一次的效果看很明确，之前的存储分配有问题。检查的过程中，出现了异常。

         往前排查，问题主要出现在了这一段逻辑。进行存储分配的时候，返回的应该是开始的地址而不是结束的地址。这也算是自己看框架不认真，其实上面的局部量中定义了一个result，多少是可以给出一点提示的。

         这是修改之后的运行效果，看得出来这部分已经测试通过。不过，在接下来的接口中又出现了失败，后面针对这些问题进一步分析解决。