1662_MIT 6.828 JOS check_page_free_list实现分析以及boot_alloc问题修复

文章详细探讨了在分析JOS代码中关于存储管理部分的内容,特别是check_page_free_list函数的作用,它根据页信息的偏移找到物理地址。作者发现并修复了一个在存储分配时返回错误地址的问题,并通过增加测试接口来验证修复效果。后续将针对新出现的失败进行进一步分析解决。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

         全部学习汇总: 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,多少是可以给出一点提示的。

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值