|
本帖最后由 不点 于 2015-8-18 18:44 编辑
又考虑了一下,觉得不要急于把整个 grub4dos 都隐藏在扩展内存顶部。可以分步骤、逐步实现。
先把 int13 代码隐藏于扩展内存顶端。主体的 grub4dos 内核仍旧在低端运行。待到以后时机成熟时,再把主体内核移动到扩展内存顶端。
目前来说,内存管理是关键。其次是进程管理。
内存管理并不难,但它是个细致活。昨天看了 grub2 的内存管理代码的注释说明,了解到 grub2 的内存管理类似于 DOS 的内存管理,是用链接表来实现内存链的。而 grub4dos 目前是用数组来管理。
我仔细考虑了两天,觉得还是数组管理更合适一些。链接表的头部占用 16 字节(或 32 字节),这不利于分配那些(例如按照扇区对齐的)内存。而数组就不存在头部,所分配到的内存是干净的,因此更有利于分配按照扇区或页面对齐的内存。那些头部的 16 字节(或 32 字节)其实是个浪费,而且更糟糕的是,它影响了所分配的内存的 “对齐性”。因此,得到的结论是,内存分配适合于用数组,不适合于用链接表。
举例来说,假如要分配 4K 内存,并且按照 4K 对齐。假定空闲空间的初始状态就是 4K 对齐的。如果用链接表,那么内存块的头部占用 16 字节,因此需要 8K 的空间才能满足 4K 对齐的要求。头部的 16 字节严重干扰了实际分配到的内存块的对齐性。
关于进程管理,觉得照样应该以简单为主要参考点。用户进程使用用户内存。内核和内核模块使用内核内存。
目前的用户进程管理模式可以继续沿用。内核的保留空间应该加大。折中一下,觉得保留 128M 给内核以及内核模块,差不多也就够用了。
内核模块的逻辑结构是由 chenall 设计的。chenall 负责有关的事宜(保证它能正常运转)。
所以,唯一需要解决的问题,便是编写 kmalloc 和 kfree 函数了。
我初步设计,0~32M 保持目前的使用状况不变。32 ~ 64M 的 32M 空间用于字体字模。64~128M 的 64M 空间用于内核的 kmalloc 分配内存。kmalloc 分配内存时,应该从顶端向下分配(就好像是堆栈那样)。因此这 64M 中的高端部分是 kmalloc 内存,而低端部分也可以被 insmod 或别的内核代码(或内核数据)占据,只要保证高端和低端不发生重叠便可。
另外想补充说明的是,既然 yaya 已经开始整理菜单界面,那么,继续支持 gfxmenu 已经没有意义了。所以新版本可以撤销对 gfxmenu 的支持。要知道,gfxmenu 占据了很大的内存开销,4M 和 6M 处各有 1M 都被保留给 gfxmenu。如果去除 gfxmenu 支持,则可以腾出宝贵的 2M 空间,供别的内核数据结构使用。
|
|