新的内存管理模块

[fslongjin]

  实现了具有优秀架构设计的新的内存管理模块，对内核空间和用户空间的内存映射、分配、释放、管理等操作进行了封装，使得内核开发者可以更加方便地进行内存管理。

  内存管理模块主要由以下类型的组件组成：

• 硬件抽象层（MemoryManagementArch） - 提供对具体处理器架构的抽象，使得内存管理模块可以在不同的处理器架构上运行
• 页面映射器（PageMapper）- 提供对虚拟地址和物理地址的映射，以及页表的创建、填写、销毁、权限管理等操作。分为两种类型：内核页表映射器（KernelMapper）和用户页表映射器（位于具体的用户地址空间结构中）
• 页面刷新器（PageFlusher） - 提供对页表的刷新操作（整表刷新、单页刷新、跨核心刷新）
• 页帧分配器（FrameAllocator） - 提供对页帧的分配、释放、管理等操作。具体来说，包括BumpAllocator、BuddyAllocator
• 小对象分配器 - 提供对小内存对象的分配、释放、管理等操作。指的是内核里面的SlabAllocator （SlabAllocator的实现目前还没有完成）
• MMIO空间管理器 - 提供对MMIO地址空间的分配、管理操作。（目前这个模块待进一步重构）
• 用户地址空间管理机制 - 提供对用户地址空间的管理。
  • VMA机制 - 提供对用户地址空间的管理，包括VMA的创建、销毁、权限管理等操作
  • 用户映射管理 - 与VMA机制共同作用，管理用户地址空间的映射
• 系统调用层 - 提供对用户空间的内存管理系统调用，包括mmap、munmap、mprotect、mremap等
• C接口兼容层 - 提供对原有的C代码的接口，是的C代码能够正常运行。

除上面的新增内容以外，其它的更改内容：

• 新增二进制加载器，以及elf的解析器
• 解决由于local_irq_save、local_irq_restore函数的汇编不规范导致影响栈行为的bug。
• 解决local_irq_save未关中断的错误。
• 修复sys_gettimeofday对timezone参数的处理的bug

[YJwu2023]

对于全局变量的修改是unsafe的，但内存模块里面不可避免地会使用到全局变量，所以有没有可能为全局变量封装函数，把unsafe块限制在对全局变量的改变上，而不外扩影响其他变量的检查。

[YJwu2023]

这个文件的注释风格怎么不太一样

[YJwu2023]

这个函数注释不太规范

[YJwu2023]

这里注释风格又突变了哈哈

[YJwu2023]

为什么不直接在头文件中声明函数,而是在文件中声明完了再在头文件中使用extern

[YJwu2023]

这里注释风格也不统一

[YJwu2023]

一个模块的全局变量有没有可能做成一个结构体，每个全局变量是一个成员，方便管理。

[fslongjin]

这玩意不行，因为这结构体恰恰是利用了它“没有成员变量”的特点，才能够被到处直接使用（不然过不了rust借用检查器的，这是主要原因）。（外面的MMArch代指的就是X86_64MMArch) 要全局变量的另一个原因，是因为它被初始化的时候，没有动态内存分配（先有鸡先有蛋的问题）

…

---原始邮件--- 发件人: ***@***.***&gt; 发送时间: 2023年7月22日(周六) 凌晨0:08 收件人: ***@***.***&gt;; 抄送: ***@***.******@***.***&gt;; 主题: Re: [DragonOS-Community/DragonOS] 新的内存管理模块 (PR #301) @YJwu2023 commented on this pull request. In kernel/src/arch/x86_64/mm/mod.rs: &gt; - let pml4t = unsafe { read_volatile(&amp;next_pcb.mm.as_ref().unwrap().pgd) }; +pub type PageMapper = + crate::mm::page::PageMapper<crate::arch::x86_64::mm::X86_64MMArch, LockedFrameAllocator&gt;; + +/// @brief 用于存储物理内存区域的数组 +static mut PHYS_MEMORY_AREAS: [PhysMemoryArea; 512] = [PhysMemoryArea { + base: PhysAddr::new(0), + size: 0, +}; 512]; + +/// 初始的CR3寄存器的值，用于内存管理初始化时，创建的第一个内核页表的位置 +static mut INITIAL_CR3_VALUE: PhysAddr = PhysAddr::new(0); + +/// 内核的第一个页表在pml4中的索引 +/// 顶级页表的[256, 512)项是内核的页表 +static KERNEL_PML4E_NO: usize = (X86_64MMArch::PHYS_OFFSET &amp; ((1 << 48) - 1)) &gt;&gt; 39; 一个模块的全局变量有没有可能做成一个结构体，每个全局变量是一个成员，方便管理。 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***&gt;

[fslongjin]

注释的问题是，最开始我们用的 @brief 格式的，不符合rust官方规范（写成markdown），后来发现写成官方规范的md，自动补全提示的时候看注释比较美观。 那几个全局变量只有在初始化内存管理的时候需要用到，因此不影响。只有内存管理模块初始化的时候才操作了他们。后面都没影响了。 extern的原因是这函数不是在c里面实现的，所以extern呀哈哈哈，不然用到可能报错。

…

---原始邮件--- 发件人: ***@***.***&gt; 发送时间: 2023年7月21日(周五) 晚上11:34 收件人: ***@***.***&gt;; 抄送: ***@***.******@***.***&gt;; 主题: Re: [DragonOS-Community/DragonOS] 新的内存管理模块 (PR #301) @YJwu2023 commented on this pull request. 对于全局变量的修改是unsafe的，但内存模块里面不可避免地会使用到全局变量，所以有没有可能为全局变量封装函数，把unsafe块限制在对全局变量的改变上，而不外扩影响其他变量的检查。 In kernel/src/mm/allocator/buddy.rs: &gt; + /// 从order转换为free_area的下标 + /// + /// # 参数 + /// + /// - `order` - order + /// + /// # 返回值 + /// + /// free_area的下标 + #[inline] + fn order2index(order: u8) -&gt; usize { + (order as usize - MIN_ORDER) as usize + } + + /// 从空闲链表的开头，取出1个指定阶数的伙伴块，如果没有，则返回None + /// 这个文件的注释风格怎么不太一样 In kernel/src/mm/allocator/page_frame.rs: &gt; +impl PageFrameCount { + // @brief 初始化PageFrameCount + pub const fn new(count: usize) -&gt; Self { + return Self(count); + } + // @brief 获取页帧数量 + pub fn data(&amp;self) -&gt; usize { + return self.0; + } + + /// 计算这一段页帧占用的字节数 + pub fn bytes(&amp;self) -&gt; usize { + return self.0 * MMArch::PAGE_SIZE; + } + + /// 将字节数转换为页帧数量 这个函数注释不太规范 In kernel/src/mm/kernel_mapper.rs: &gt; + if self.readonly { + return None; + } else { + return Some(&amp;mut self.mapper); + } + } + + /// @brief 获取内核映射器的page mapper的不可变引用 + #[inline(always)] + pub fn as_ref(&amp;self) -&gt; &amp;PageMapper { + return &amp;self.mapper; + } + + /// 映射一段物理地址到指定的虚拟地址。 + /// + /// ## 参数 这里注释风格又突变了哈哈 In kernel/src/mm/mmio.h: &gt; @@ -1,7 +1,5 @@ #pragma once #include "mm.h" -extern void mmio_buddy_init(); -extern void mmio_create(); +extern void mmio_create(uint32_t size, uint64_t vm_flagsu, uint64_t* res_vaddr, uint64_t* res_length); 为什么不直接在头文件中声明函数,而是在文件中声明完了再在头文件中使用extern In kernel/src/mm/page.rs: &gt; + /// 获取当前页表的第i个页表项 + pub unsafe fn entry(&amp;self, i: usize) -&gt; Option<PageEntry<Arch&gt;&gt; { + let entry_virt = self.entry_virt(i)?; + return Some(PageEntry::new(Arch::read::<usize&gt;(entry_virt))); + } + + /// 设置当前页表的第i个页表项 + pub unsafe fn set_entry(&amp;self, i: usize, entry: PageEntry<Arch&gt;) -&gt; Option<()&gt; { + let entry_virt = self.entry_virt(i)?; + Arch::write::<usize&gt;(entry_virt, entry.data()); + return Some(()); + } + + /// 判断当前页表的第i个页表项是否已经填写了值 + /// + /// ## 参数 这里注释风格也不统一 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***&gt;