【需求讨论】关于multiboot2模块重写的一些问题

我在完成之前的社区任务,使用rust重写multiboot2模块,现在遇到一些选择:

  1. 是单纯的使用rust“翻译”原始的C代码,比如:
    // The multiboot header struct
    #[repr(C)]
    pub struct MultibootHeader {
        // Must be MULTIBOOT2_HEADER_MAGIC
        pub magic: u32,
        // ISA
        pub architecture: u32,
        // Total header length
        pub header_length: u32,
        // Checksum of the above fields
        pub checksum: u32,
    }

还是给各类tag类型增加细粒度的抽象:比如:

#[derive(Copy, Clone, PartialEq, Eq, PartialOrd, Ord, Hash)]
#[repr(C, packed)]
pub struct VBEControlInfo {
    /// VBE Signature aka "VESA".
    pub signature: [u8; 4],

    /// The VBE version.
    pub version: u16,

    /// A far pointer the the OEM String.
    pub oem_string_ptr: u32,

    /// Capabilities of the graphics controller.
    pub capabilities: VBECapabilities,

    /// Far pointer to the video mode list.
    pub mode_list_ptr: u32,

    /// Number of 64KiB memory blocks (Added for VBE 2.0+).
    pub total_memory: u16,

    /// VBE implementation software revision.
    pub oem_software_revision: u16,

    /// Far pointer to the vendor name string.
    pub oem_vendor_name_ptr: u32,

    /// Far pointer to the product name string.
    pub oem_product_name_ptr: u32,

    /// Far pointer to the product revision string.
    pub oem_product_revision_ptr: u32,

    /// Reserved for VBE implementation scratch area.
    reserved: [u8; 222],

    /// Data area for OEM strings.
    oem_data: [u8; 256],
}
  1. 是否需要 construct a Multiboot2 header at runtime,这样的话需要增加一些DST的类型(比如需要引入helper type to create boxed DST)
  2. 如果后续还需要增加其他引导协议的话,这个引导协议与kernel的接口(目前使用的multiboot2)是不是也要增加抽象呢?
1 个赞

感觉后者更符合rust的逻辑?哈哈哈

目前我在写riscv的移植(用的uboot+dragonstub),按照目前的想法,也许不需要加抽象了,暂时感觉用不到。

好嘞,那就按照第二个选择来

1 个赞