总结报告

第一周练习

练习1是输出彩色字体，实现并不难。

练习2是移植hashmap，我将标准库里的 hashmap 拷贝过来，先全部注释掉，再根据测试结果逐步的去解除注释

练习三和四是实现内存分配算法和解析 fdt，解析 fdt 使用了群友推荐的库。

练习5是抢占式的 fifo，只需要将 rr 里面的抢占的代码移植过来

第二周练习

练习1 && 2

镜像格式：

|app_num|app_size|app_data|app_size|app_data|…|

一开始使用dd写入的时候一直无法读取第二个app，后来通过 hexdump 去解析镜像文件发现了问题在哪，进行了相应的修改。

练习 3

需要去掉 noreturn，让函数返回

练习 4

练习3使用 axstd 里面提供的 exit 方法就可以完成这个实验

练习 5

练习4需要注意寄存器 a7 被 rust 修改，每次调用完后需要重新设置 a7 的值，或者第一次返回的时候就保存好入口地址，以后就使用这个入口地址，还需要加上clobber_abi("C")。遍历字符串的时候使用 bytes 来迭代。

练习 6

需要先读取 app_num 和 app_size。其他就移植练习5过来就行。

代码仓库：https://github.com/uran0sH/arceos

总结报告

很高兴参加第三阶段ArceOS Unikernel的课程学习与训练，
经过第三阶段的学习，让我对rust、unikernel、linux等都有了更深入的理解。经过这些实验与练习，提升了我对rust语言的理解，感受到rust的条件编译的强大。学习了ArceOS的层次结构、模块化设计理念，让我对Unikernel的概念有了更具象化的理解。十分感谢石磊老师的细心讲解、助教老师孙应娥的热心帮忙以及群里的同学们的讨论指导。

下面是逐个练习的总结与反思。

第一周练习

练习 1 &2

练习1

支持彩色打印println!。以apps/helloworld为测试应用。
要求：不能在helloworld程序本身改，要在下面的库或更深层次的组件修改

练习2(附加题)

支持HashMap数据类型。以apps/memtest为测试应用。
要求：在ulib/axstd中支持HashMap类型

预期输出：执行 make A=apps/memtest ARCH=riscv64 run

思路：练习1就是在println!宏的实现上添加带颜色的格式控制就可以了。
练习2根据提示是参考rust官方的hash表实现，但是官方实现内容太多了，错综复杂的依赖不好解决。根据老师在群里的提示，只需要实现测试用到的函数(new、iter、insert等)就好了，然后就顺利解决了。

我在参考官方库的时候，发现官方库实际是在 用hashbrown::hash_map，进行二次封装的。所以这个练习有一个偷懒的做法

1

use hashbrown::hash_map as HashMap;

练习3

练习3

为内存分配器实现新的内存算法early，禁用其它算法。early分配算法以apps/memtest为测试应用。

这题是我卡的最久的一个练习，我一开始以为需要涉及底层内存的分配(实际上是分配好底层的内存了)，实际上为了简化练习，底层内存已经分配固定了，只是需要给应用分配地址。
因此我一开始走了很多弯路，我的原本的想法是将byteAllocator和pageAllocator进行结合，或者是使用byteAllocator和BitAlloc结合。导致这样的想法是为以为BitAlloc是会控制底层的内存分配(不得不说实在太蠢了)。

尝试了各种方法后，请教了王格格同学，知道了正确的做法:维护byte_pos和page_pos来进行内存分配就好了。

实际的细节中要注意内存地址的对齐，为在练习5中发现了在练习3中的问题。即内存地址的大小和地址都要进行对齐。

练习4

解析dtb(FDT的二进制格式)，打印物理内存范围和所有的virtio_mmio范围。以apps/memtest为测试应
用。
当ArceOS启动时，上一级SBI向我们传递了dtb的指针，一直会传递到axruntime，我们就在
axruntime中执行解析并打印。

思路：需要查阅相关资料，了解DTB，了解FDT相关的内容。感谢群里的郝淼同学分享的hermit-dtb库，解析dtb很方便。在解析的过程中需要注意的点是内存地址和大小的字段在reg字段中，需要将reg一分为二。

练习5

练习5

把协作式调度算法fifo改造为抢占式调度算法。让测试应用通过

难点：主要是要理解arcos中的调度模块的代码，启用preemt的feature。

第二周练习

练习1&2

练习 1：

main 函数中，固定设置 app_size = 32，这个显然是不合理甚至危险的。
请为 image 设计一个头结构，包含应用的长度信息，loader 在加载应用时获取它的实际大小。执行通过。

练习 2：

在练习 1 的基础上，扩展 image 头结构，让 image 可以包含两个应用。
第二个应用包含唯一的汇编代码是 ebreak 。
如实验 1 的方式，打印出每一个应用的二进制代码

练习1和练习2是关系紧密的，都是要给image添加文件头，可以直接做练习2。

我们需要知道应用的数量，以及每个应用的字节长度，所以很自然地可以想到，首先文件头第一个字段应该是 应用数量，然后接着是每个应用的应用大小,最后是每个应用的应用二进制内容。

因此我设计的文件格式如下
| field| length|
| ———– | ———– |
| app_amount| 2 bytes|
| app0_size | 2 bytes|
| app1_size | 2 bytes|
| …… | 2 bytes|
| appn_size | 2 bytes|
| app0_bin | app0_size bytes|
| app1_bin | app1_size bytes|
| ……. | …….|
| appn_bin | appn_size bytes|

应用数量和应用大小字段长度都是2个字节,因此我用rust写了个小程序将文件头写入文件。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

//参数是 需要合并的app文件名称
let mut args =env::args();
args.next();
let files_number:u16=args.len() as u16;

let mut output_file: File =File::create("new_apps.bin").expect("open fails");
output_file.write(&files_number.to_be_bytes()).expect("write file numbers fails");

for file in args{
    let length:u16= fs::metadata(file.clone()).expect("open file fails").len() as u16;
    println!("APP:{}:{}",file,length);
    output_file.write(&length.to_be_bytes()).expect("writing file length fails");

}
args=env::args();
args.next();
for file in args{
    let mut source_file=File::open(file).expect("Opening file fails");
    let mut buffer=Vec::new();
    source_file.read_to_end(&mut buffer).expect("reading file fails.");
    output_file.write_all(&buffer).expect("writing file fails.");
}

相应的在arcos中的loader程序就要先读取前两个字节，获取app数量，然后再依次读取app长度和app的内容

要注意的细节：要维持文件大小在32M,否则qemu无法加载，文件大小在Makefile文件中写死了。

练习3

练习 3：

批处理方式执行两个单行代码应用，第一个应用的单行代码是 nop ，第二个的是 wfi

思路：如何把控制权重新回到arceos中，重新返回到loader中执行

练习4

练习 4：

本实验已经实现了1 号调用 - SYS_HELLO，2 号调用 - SYS_PUTCHAR，请实现 3 号调用 -
SYS_TERMINATE 功能调用，作用是让 ArceOS 退出，相当于 OS 关机。

思路：熟悉arceOS的代码，寻找相关的模块代码。我的想法是关机的调用实际上是应该控制硬件来进行操作的，可能跟sbi相关的，应该在硬件抽象层，所以为主要是看了axhal模块的代码。然后发现了相关的调用代码

1
2
3
4
5
6
7
8
9

/// Shutdown the whole system, including all CPUs.
pub fn terminate() -> ! {
    info!("Shutting down...");
    sbi_rt::system_reset(sbi_rt::Shutdown, sbi_rt::NoReason);
    warn!("It should shutdown!");
    loop {
        crate::arch::halt();
    }
}

所以只需要在loader中调用这个terminate函数就可以实现关机操作。

练习5

练习5

照如下要求改造应用 hello_app：

1. 把三个功能调用的汇编实现封装为函数，以普通函数方式调用。例如，SYS_PUTCHAR 封装为
   fn putchar(c: char) 。
2. 基于打印字符函数 putchar 实现一个高级函数 fn puts(s: &str) ，可以支持输出字符串。
3. 应用 hello_app 的执行顺序是：Hello 功能、打印字符串功能、退出功能。

思路：将三部分调用的内联汇编代码都封装在函数中，在入口函数中顺序调用即可。

看样子不难的程序我又卡了很久很久，跟编译器斗智斗勇了很久。

1
2
3
4
5
6

unsafe extern "C" fn _start(_entry:usize){
    ENTRY=_entry;
    hello();
    puts("ArceOS exercise 5.");
    terminate();
}

理想的执行过程是依次调用hello、puts、terminate函数后退出。但是无论怎么尝试，程序只会执行第一个调用的函数后退出。我就很疑惑:能够执行第一个调用的函数，那说明我的函数封装应该没有问题，可是为什么无论调用多少次，只会执行一次。而且调用多少次都不会改变编译生成的文件大小。然后我又生成了汇编代码进行查看。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

_start:
	addi	sp, sp, -32
	sd	ra, 24(sp)
	sd	s0, 16(sp)
	sd	s1, 8(sp)
	sd	s2, 0(sp)
	addi	s0, sp, 32
	mv	s1, a0
.Lpcrel_hi0:
	auipc	s2, %pcrel_hi(_ZN9hello_app5ENTRY17hc4afe4ceb535dcc3E.0)
	sd	a0, %pcrel_lo(.Lpcrel_hi0)(s2)
	mv	t2, a0
	#APP

	li	t0, 1
	mv	a7, t2
	slli	t0, t0, 3
	add	t1, a7, t0
	ld	t1, 0(t1)
	jalr	t1

	#NO_APP
	ld	a0, %pcrel_lo(.Lpcrel_hi0)(s2)
	bne	a0, s1, .LBB0_2
	ld	ra, 24(sp)
	ld	s0, 16(sp)
	ld	s1, 8(sp)
	ld	s2, 0(sp)
	addi	sp, sp, 32
	ret

然后发现start内确实只有我第一个调用函数的汇编代码。难道是为我的代码被编译器给优化了?
然后尝试了各种方法，改成debug模式，修改优化等级，修改使用的寄存器等。比如在Cargo.toml中修改优化等级为0。

1
2

[profile.dev]
opt-level = 0

均没有任何效果。
然后为又重新审视了每个汇编代码块。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

unsafe fn hello() {
        core::arch::asm!("
        li t0, {abi_num}
        mv a7,t2
        slli t0, t0, 3
        add t1, a7, t0
        ld t1, (t1)
        jalr t1
        ",
        abi_num = const SYS_HELLO,
        in("t2") ENTRY,
        clobber_abi("C"),     // 告诉编译器 clobber 了通用寄存器
        options(noreturn) 
        )
}

然后发现了问题所在:options(noreturn)是告诉编译器这段汇编代码没有返回，也就是说后面的代码永远也不会执行，因此编译器会把后面调用的函数代码全都丢掉。因此只会执行第一次函数调用。注释掉即可解决问题。

练习6

练习 6：

1. 仿照 hello_app 再实现一个应用，唯一功能是打印字符 ‘D’。
2. 现在有两个应用，让它们分别有自己的地址空间。
3. 让 loader 顺序加载、执行这两个应用。这里有个问题，第一个应用打印后，不能进行无限循环
   之类的阻塞，想办法让控制权回到 loader，再由 loader 执行下一个应用。

思路:需要为每个应用分配独立的地址空间，并在跳转到app之前切换到app的地址空间，返回时再重新切换回内核空间。

因此在切换到app的地址空间之前，需要先保存当前的satp寄存器的值，执行完app后重新加载。

2023秋冬季开源操作系统训练营第三阶段总结报告

练习一、二

练习要求

练习 1：
main 函数中，固定设置 app_size = 32，这个显然是不合理甚至危险的。
请为 image 设计一个头结构，包含应用的长度信息，loader 在加载应用时获取它的实际大小。
执行通过。
练习 2：
在练习 1 的基础上，扩展 image 头结构，让 image 可以包含两个应用。
第二个应用包含唯一的汇编代码是 ebreak 。
如实验 1 的方式，打印出每一个应用的二进制代码。

实现过程

根据练习一、二的要求设计 image 结构如下图所示。

image 文件中的首 0-7 的字节用于存放 ‘app 数量’，用以告诉加载器整个 image 中包含有多少个 app。后续的内容以 ‘app 数量’ 个的 app 结构块组成，每个 app 结构块 的首个 32 字节存放当前 app 的块数量，第二个 32 字节存放不满足块大小的 ‘余量’。
‘app 块大小’ 默认定义为 1024 ，即一个块大小为 1024 字节。app 的 ‘块数量’ 则为 ‘app 二进制文件大小除以 app 块大小’。’余量’定义为不满足一个块大小的剩余长度，表示为 ‘app 二进制文件大小除以 app 块大小的余数’。
跟据上述的定义，将 app 二进制文件修改为以 ‘.app’ 后缀结尾的文件，依托于 rust 的构建脚本 build.rs 查找指定目录下的 app 文件，生成上述格式的 image 文件，同时使用 dd 命令完成文件合并，需要保证 * pflash 文件必须为 32MB 大小*。
后续在 loader 中完成对 image 的解析，并在 app 需要执行时将 app 字节码内容拷贝到指定地址后，跳转到相应地址执行 app 内容。 app 结构定义 如下：

1
2
3
4

struct App<'a> {
    size: u32,	    size: usize,
    code: &'a [u8],	    code: &'a [u8],
}

练习三

练习要求

练习 3：
批处理方式执行两个单行代码应用，第一个应用的单行代码是 nop，第二个的是 wfi。

实现过程

根据上一节的练习添加第二个应用，在第一个应用执行完成后并没有返回到 loader 执行下一个下一个应用，根据调试分析，在第一个应用中并没有返回到 loader 的相关代码，需要添加添加相关代码才能返回到 loader 执行下一个 app。在每个 app 的代码中添加 ‘ret’ 指令，并删除 ‘options(noreturn)’ 以及函数的 ‘永不返回’ 标识 ‘!’，以完成在 app 执行结束后跳转回 loader。同时在构建 image 的时候需要注意 app 的顺序。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

#![no_std]
#![no_main]

use core::panic::PanicInfo;

#[no_mangle]
unsafe extern "C" fn _start() {
    core::arch::asm!(
        "
        nop
        ret
        "
    )
}

#[panic_handler]
fn panic(_info: &PanicInfo) -> ! {
    loop {}
}

练习四

练习要求

练习 4：
本实验已经实现了1 号调用 - SYS_HELLO，2 号调用 - SYS_PUTCHAR，请实现 3 号调用 - SYS_TERMINATE 功能调用，作用是让 ArceOS 退出，相当于 OS 关机。

实现过程

仿照 SYS_PUTCHAR 的实现，调用 axhstd 提供的 exit 函数完成相关功能个即可。

练习五

练习要求

练习 5：
按照如下要求改造应用 hello_app：

1.把三个功能调用的汇编实现封装为函数，以普通函数方式调用。例如，SYS_PUTCHAR 封装为 fn putchar(c: char)。
2.基于打印字符函数 putchar 实现一个高级函数 fn puts(s: &str)，可以支持输出字符串。
3.应用 hello_app 的执行顺序是：Hello 功能、打印字符串功能、退出功能。

实现过程

根据实验文档，ABI_TABLE 的基地址保存在 a7 寄存器中，在进入 app 时将 a7 寄存器的内容保。同时将 ABI 函数的调用逻辑封装为函数 ‘abi_call’，需要注意使用 ‘clobber_abi(“C”)’ 完成对寄存器的保存，同时指定 app 的 链接文件，以指定字符串存放位置。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

/// abi 调用函数
unsafe fn abi_call(addr: usize, abi_num: usize, arg0: usize) {
    core::arch::asm!("
        mv      a7, {abi_addr}
        mv      t0, {abi_num}
        slli    t0, t0, 3
        add     t1, a7, t0
        ld      t1, (t1)
        jalr    t1",
    abi_addr = in(reg) addr,
    abi_num = in(reg) abi_num,
    in("a0") arg0,
    clobber_abi("C")
    )
}

练习六

练习要求

练习 6：
1.仿照 hello_app 再实现一个应用，唯一功能是打印字符 ‘D’
2.现在有两个应用，让它们分别有自己的地址空间。
3.让 loader 顺序加载、执行这两个应用。这里有个问题，第一个应用打印后，不能进行无限循环之类的阻塞，想办法让控制权回到 loader，再由 loader 执行下一个应用。

实现过程

在练习五的基础上，仿照 ‘hell_app’ 实现另一个 app，同时需要避免 app 中的 ‘wif’ 和无限循环等阻塞操作，避免不能返回 ‘loader’ 执行下一个 app。

总结

本次实验和练习加深了我对操作系统的理解，同时也学习了组件化操作系统 unikernel 的相关知识、对 qemu 的使用更加熟练的同时也学习了 pflash 相关的知识。对 rust 的嵌入式汇编及相关知识的掌握更加深入。同时也感谢各位老师的对本次课程的知识讲解，也感谢各位同学在群里提出的的问题以及解决方案。

总结报告

第一周实验总结

exercise 1&2: 改变println！宏以及引入haspmap

这里我是直接查询chatgpt知道可以通过在println!加入特殊符号来改变颜色,于是改变了底层的println!实现了。

后者我则是有点找不着头脑，因为本身的rust基础就是训练营的第一周和第二周，而这种程度根本无法跟得上后续的项目级别的开发，二阶段也只是调用api，到了第三阶段才发现自己连cargo管理项目和lib.rs文件都不知道是什么作用,导致自己花了很多时间去找bug,后来通过在项目群里询问大佬才发现自己的问题，当然对于引入hashmap的操作，也是借鉴了石磊老师的注释大法，通过报错信息和一步步释放自己想要的代码来逐步达到目的，这让我节省了很多时间。

exercise 3&4 引入early算法和解析dtb文件

前者我是直接通过将buddy算法和bitmap算法两个内存分配和页分配的算法结合起来拼凑起来实现的。

后者我是通过使用群里大佬分享的库，以及询问邝劲强大佬关于库的使用方法，他给予了我一些提示，于是成功实现了这个练习。

exercise 5 将协作式调度算法fifo改造为抢占式调度算法

这里我是直接参考了round_robin.算法的实现进行修改，然后比较顺利的通过。

第二周实验总结

exercise 1&2

这里我使用了非常规的方法，直接使用了脚本来获取文件大小等信息

后者通过脚本将两个文件合并到一起，后来才发现这种做法是不可取的，少了在loader的一环,这也导致我后续练习5的bug找了很久。

exercise 3&4

这两个实验则相对于简单很多，第一个实验就是改一下汇编代码’nop’和’wfi’

后者就是仿照puthello和putchar然后加一个axstd::process::exit函数的调用就行了。

exercise 5&6

其实在我心目中，反而是第一个和第二个实验最难，我对文件那块不太熟悉，练习5和练习6的思路和策略我觉得想得很快，无非是因为要写内联汇编而已，这里我也是首先犯了没有保存a7寄存器的错误，后续发现不再是loadfault的错误而是IllegalInstruction的错误信息，一直找不到错误的重点在哪里，在此过程中，在助教和群友的帮助下，尝试了通过其他寄存器如s11来保存a7，通过全局静态变量来保存a7寄存器，通过在loader传入a0而非a7寄存器到helloapp的_start函数的第一个参数来保存abi表地址一共三个办法，得出一定不是

helloapp本身的问题，而是loader的文件，然后通过排查，发现是load_size的大小太小了，一直写得指导书的32，后面改大一点通过了

练习6意识到需要改正练习1和练习2没有在loader加入头结构和相关函数的问题，于是添加上去，实现了分别调用两个地址空间的应用。

第一周练习总结

第一周的 5 个练习的主要目的是了解 ArceOS 的基本代码组织结构，为后面的任务打下基础。

练习 1、2

练习 1 要求实现彩色打印 println!，这个任务我采用了修改 axstd::println! 来实现，这是出于架构兼容性的考虑，不应修改太过底层的代码。具体实现是利用了 ANSI 转义序列。

练习 2 要求支持 HashMap 并通过测试。之所以 Rust 核心库中没有 HashMap，是因为 HashMap 需要调用产生随机数的接口，而这个接口是架构相关的。因此，练习 2 的核心是实现 axstd 可调用的 fn random() -> u128 接口。

自底向上实现 random 的过程：

• axhal::random::random()：在 axhal 层实现架构相关的 random() 接口，它调用了 axhal::time::current_ticks()
• arceos_api::random::ax_random()：定义 ax_random 接口，通过 pub use axhal::random::random as ax_random; 将其直接实现为 axhal::random::random()
• 在 axstd 中可调用 arceos_api::random::ax_random()

练习 3、4

练习 3 要求实现内存分配器 early。ArceOS 中包含两个内存分配器 palloc 和 balloc，palloc 用于以页单位的内存分配，balloc 被指定为 Rust 的 #[global_allocator]，这样我们就可以使用 Rust 中如 Vec，String 等这些堆上可变长的数据类型。这两个内存分配器都包含在一个全局内存分配器 GLOBAL_ALLOCATOR 中。

early 分配器既是 palloc 又是 balloc，因此这里遇到一个问题：GLOBAL_ALLOCATOR 中使用了一对智能指针分别指向了 palloc 和 balloc 实例，但由于 early 分配器的特点，early 在全局只有一个实例，并且其中的 palloc 和 balloc 还需要共享数据。

因此，我将 GLOBAL_ALLOCATOR 可能的类型分为两种：

• SeparateAllocator：分离式内存分配器，palloc 和 balloc 是两个，当 balloc 可用内存不足时，向 palloc 请求内存
• AIOAllocator：一体式内存分配器，palloc 和 balloc 是同一个，两个内存分配器中共享剩余可用内存

此外，我定义了 trait GlobalAllocator，与原来的 GlobalAllocator 类中实现的方法保持一致。而后，为 SeparateAllocator 和 AIOAllocator 分别实现 GlobalAllocator，然后在 toml 中增加关于 early 的选项，即可达成练习目标。

练习 4 要求通过 rust_main() 的参数 dtb 解析 dtb。这一练习的关键是找到一个合适的 crate，我使用的是 hermit-dtb = "0.1.1"。

练习 5

练习 5 要求将 FIFO 算法改变为抢占式的。FIFO 算法原本维护了一个队列，靠进程主动放弃 CPU 触发调度。在抢占式中，需要将原本的 List 修改为双端队列 VecDequeue，这样在 remove_task(&mut self, task: &Self::SchedItem) 中，修改为先找到 task 的下标，然后根据下标将其从队列中删除；在 put_prev_task(&mut self, prev: Self::SchedItem, preempt: bool) 如果此时是可以抢占的，就将 prev 放入队尾，否则将其放在队头，相当于调度器选择的还是当前的任务；最后，将 task_tick 的返回值恒置为 true 这样每次时钟中断发生时都能进行调度。

第二周练习总结

第二周在一个个小练习后逐渐实现了一个可以加载二进制文件的 loader，并且加载的应用有独立的地址空间。

练习 1、2

实际上练习1、2的任务是实现一个简易的文件系统。我的设计如下：

1
2
3
4
5
6
7

struct ImgHeader {
    app_num: usize,
}

struct AppHeader {
    app_size: usize,
}

将 1 个 ImgHeader 放在 pflash 头部，而后紧接着app_num 个 AppHeader 用于指示每个应用的大小。

生成二进制镜像，添加这写头部信息我是用 C 语言实现的，在此不再赘述。

练习 3

批处理的方式下，先加载第一个应用，然后运行；而后加载第二个应用，然后运行。这两个应用均被加载到一个固定的地址。

在 loader 中，使用 jalr 指令通过函数调用执行一个应用，因此，在进入应用程序的主函数时，ra 寄存器已经被加载为返回地址，想要从应用程序返回，只需要将函数签名返回值部分的 -> ! 改为 -> () 或者直接删除即可。这样，应用程序生成的汇编代码最后是一条 ret 指令，恰好能返回到 loader。

练习 4、5

练习 4 将 sys_terminate 封装为对 axstd::process::exit 的调用即可。

练习 5 我将所有的 abi 调用和为一个分发函数：

1
2
3
4
5
6
7
8

fn abi_entry(abi_num: usize, arg0: usize) {
    match abi_num {
        SYS_HELLO => abi_hello(),
        SYS_PUTCHAR => abi_putchar(arg0 as u8 as char),
        SYS_TERMINATE => abi_terminate(arg0 as i32),
        _ => panic!("unsupport abi call!"),
    }
}

然后将这个函数的地址作为第一个参数传入应用，即通过 a0 传参：

1

unsafe extern "C" fn _start(abi_entry: usize) -> !

在应用中，封装 putchar 等函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

fn putchar(c: u8) {
    unsafe {
        core::arch::asm!("
            li      a0, {abi_num}
            la      t0, {abi_entry_addr}
            ld      t0, (t0)
            jalr    t0",
            abi_num = const SYS_PUTCHAR,
            abi_entry_addr = sym ABI_ENTRY,
            in("a1") c,
            clobber_abi("C"),
        )
    }
}

实际上，所有 abi 函数都是跳转到 abi_entry 执行，不同之处在与参数的传递，我规定第一个参数 a0 是 abi 号，后面的是 abi 函数的参数。在 putchar 中，a0 被设置为 SYS_PUTCHAR，a1 被设置为 c 的值。注意，在内联汇编的结尾要加上 clobber_abi("C")，保持寄存器在执行这段汇编代码前后的一致，否则将出现混乱。

练习 6

目前，在批处理且每个应用地址空间相同的情况下，练习 6 实现起来比较简单，保持每个应用复用全局的应用页表 APP_PT_SV39 即可。

总结报告

练习1：为 image 设计一个头结构，包含应用的长度信息，loader 在加载应用时获取它的实际大小

这个实验刚开始的时候一头误水，以为是生成镜像后，让loader自己判断应用长度和个数，发现很难实现，后面才发现练习1的要求是在image开头加入应用长度信息，这样loader只需要获取相应的信息就可以获取实际大小和个数，实现非常轻松，后面才了解到例如elf等文件，都会有相应的头部信息给loader进行判断。

应用头

1
2
3
4
5

struct AppHeader {
    start: usize,
    size: usize,
    content: &'static [u8],
}

后面感谢邝劲强同学提供了一个生成镜像的脚本思路，以及dd中seek选着字节跳过的用法。

练习 2：在练习 1 的基础上，扩展 image 头结构，让 image 可以包含两个应用

在完成练习1后，练习2就变得很轻松了，顺着练习1的思路只需要在镜像开头加入应用个数的信息，然后loader获取后，循环调用每一个app即可。

镜像头：

1
2
3

struct ImageHeader{
    ptr_len: usize
}

循环调用：

1
2
3
4
5
6
7
8
9

let mut app_start = PLASH_START + ptr_len;
for _ in 0..app_nums {
    let app_header = image_header.load_app(app_start);
    println!("start:{:#}",app_header.start);
    println!("size:{}", app_header.size);
    println!("context:{:?}",app_header.content);
    println!("......................................");
    app_start += app_header.size + ptr_len;
}

练习3：批处理方式执行两个单行代码应用，第一个应用的单行代码是 nop ，第二个的是 wfi

刚开始没注意到改文档了，写的noop，然后直接报错了，调试了一下，最后看群里面才发现是nop。然后好像就没什么了，把实验2的实现放在练习3就行了。

练习4 请实现 3 号调用 -SYS_TERMINATE 功能调用，作用是让 ArceOS 退出，相当于 OS关机

这个在前面的学习中已经发现axstd中已经实现了axstd::process::exit，只需要封装下调用即可，还是比较简单的。

练习5: 按照要求改造应用 hello_app

这个应该是6个练习中最难的一个，刚开始按照实验4的思路把汇编指令全部移动到了外部的镜像中，但是和实验4不同的是，这里会执行3个系统调用（应该是大于三个的，因为打印字符串，吊调用了多次putchar），然后我执行完第一个后就发生panic，然后为对riscv汇编指令不熟，也不知道如何查看寄存器状态，这里感谢刘逸珑同学大半夜了教我如何使用gdb，最后发现是a7寄存器的值发生了改变，即原本传入的abi_table，在调用第一个函数后a7的值发生了改变，后面发现是在执行后axhal调用了a7,存了一下值，于是问题就简单了，用一个t2寄存器存一下a7的值即可。
实现的代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

fn hello() {
    unsafe {
        core::arch::asm!("
            li t0, {abi_num}
            slli t0, t0, 3
            add t1, a7, t0
            mv t2,a7
            ld t1, (t1)
            jalr t1
            mv a7,t2",
            abi_num = const SYS_HELLO,
            clobber_abi("C")
        )
    }
}

fn putchar(c: u8) {
    unsafe {
        core::arch::asm!("
            li t0, {abi_num}
            slli t0, t0, 3
            add t1, a7, t0
            mv t2,a7
            ld t1, (t1)
            jalr t1
            mv a7,t2",
            clobber_abi("C"),
            abi_num = const SYS_PUTCHAR,
            in("a0") c,
            
    )}
}

fn terminate(exit_code: i32) {
    unsafe {
        core::arch::asm!("
            li t0, {abi_num}
            slli t0, t0, 3
            add t1, a7, t0
            mv t2,a7
            ld t1, (t1)
            jalr t1
            mv a7,t2",
            abi_num = const SYS_TERMINATE,
            in("a0") exit_code as u8,
            clobber_abi("C")
        )
    }
 
}

练习6：

1. 仿照 hello_app 再实现一个应用，唯一功能是打印字符 ‘D’。
2. 现在有两个应用，让它们分别有自己的地址空间。
3. 让 loader 顺序加载、执行这两个应用。这里有个问题，第一个应用打印后，不能进行无限循环
   之类的阻塞，想办法让控制权回到 loader，再由 loader 执行下一个应用。

这个比较简单只需要在练习5的基础上使用putchar函数,并且删除wfi,让程序不要等待中断即可。

个人总结

刚开始我每个项目都进去听了一下，最后被arceos的组件化思想给吸引了，加上老师上课任务都很用心，因为平时还有课，就专注于项目1了，收获不小，rust和unikernel，甚至如何编写makefile 都是在从这次开源活动中学习到的，尤其是项目1。最让我深刻的就是自己编写makefile然后成功让镜像加入到了loader里面并运行，和练习5调试那个汇编代码和寄存器，这两个地方，解决困难后的兴奋感。

2023秋冬季开源操作系统训练营总结

一些碎碎念

我是一个普通的大三学生，目前就读于厦门大学计算机科学与技术系。不得不吐槽一下学校的课程设置，从本学期（也就是大三秋季学期）开始才开设计算机组成原理、计算机网络、汇编语言等计算机专业课程，至于操作系统、编译原理、计算机系统结构等等直到下个学期才会开设。当然也许学校的课程安排也有他的道理，现在慢慢意识到以前觉得又难又没有意义的课，比如说模拟电子技术、数字电子技术、计算方法等，这些课在现在的学习中或多或少都有涉及到，然后学起来甚至有点亲切感（）。

前言

言归正传，相比于计算机专业的其他课程，我最感兴趣的应该就是操作系统了。虽然说也说不出来原因，也许是因为操作系统四个字看起来比较高级（？），在平常没事做的时候就自学了一遍学校的课程，通读过操作系统导论和现代操作系统两本书，但是一切都仅局限于理论层次上，一直真正实际动手设计一个操作系统。这里不得不提到MIT的6s081,曾经试着做了一点点lab，但是因为各种原因，只开了个头就弃坑了。一次偶然的机会了解到了清华大学开源操作系统训练营，遂欣然报名。

一阶段

一阶段的任务主要是熟悉一下Rust的语法，通过rustling对Rust有了个初步的认识。（虽然于我个人来说好像并没有多大作用…该看不懂的还是看不懂…） 也算蛮顺利地完成了，为之后的学习增加了很多的信心。

二阶段

二阶段相当的煎熬。

你已经熟悉了Rust的基本语法啦，现在请你动手用Rust搓一个OS出来。

对，差不多就是这种感觉。

整个的学习过程就差不多是，道理都明白，但是无从下手。比如说这个函数要加在哪个文件里，这里要干什么，unwrap是什么,……….，rust-analyzer真是帮了很大的忙就是说。
然后不出意料地卡关了，而且还适逢期中考试周，研究了两三天没什么成果后就弃坑去复习期中考试的内容了。考试结束后又重新捡起来看，发现之前悟到的那一点点东西也差不多全忘了。。。

在群里潜水看大佬们的讨论，才发现原来有 rCore-Tutorial-Guide-2023A 这个详细的指导书存在… 整个知识结构比适用于本次训练营的精简版清晰了不要太多。于是从头把到第五章为止的指导书阅读了一遍，感觉之前很多疑惑的问题在心里都有了答案（虽然也理解的不是很透彻）。
至于编程题的代码，啊作为Rust的初学者真是相当的头疼…于是到处借鉴了大佬们的代码，在大佬们的大框架下结合自己的想法进行修改，感受就是：哦原来这个在rust里应该这样写。

勉勉强强算是把二阶段完成了，回头思考二阶段的三个lab真是有轻舟已过万重山的感觉，一切都显得那么合理，但是让我从零开始写真是相当困难的一件事。也许原因是对Rust还不够熟悉吧，下一阶段的学习目标是把Rust系统的学习一遍。

三阶段

个人觉得达不到二阶段的考核要求，因此对于三阶段不抱什么希望，而且就算是参加了感觉也够呛能完成…

总结

感谢清华大学提供的这样一个学习机会，相比于我本科学校的纯理论教学，rCore和uCore属于是降维打击了，本次训练营的学习开拓了我的视野。有机会的话我会继续参加明年的训练营，希望在明年的时候能够以一个强大的自己来完成训练营的训练项目。

第三阶段总结报告

第一周

完成了三阶段的第二周的练习，我要诚实的说这对我来说并不容易

先来说说第一周的练习吧 第一周的练习 现在可能做完了所以觉得不难

实际上hashmap源码的删减就让我头疼 由于rust的语言特性实现hashmap似乎要比其他语言难不少 其他也就感觉还好

练习三需要实现一个内存分配算法 在这里我遇到了一些问题 在邝劲强同学的帮助下（他给予了我一些指导）完成了

后面的练习也都较为顺利的完成

第二周

涉及到arceos的外部应用的引用，实验嘛 代码什么的都提供了 很顺利的就完成了，然而到了练习的阶段，完全没思路 看着和我同为大二的新认识的同学顺利的推动着进度 但是我却没进展 心里十分焦急，

尝试了很多次 创建了不知道多少副本 不是跑不通就是panic 内存访问有问题，在百思不得其解下 我得到了王格格同学的指导 她细心的指导了我最后一点没想明白的地方（app.bin 如何被arceos调用），懂得了这一点内容，我后面的练习推动就能正常进行了，完成了联系一和二，接下来的3和4也都比较简单，然后是到了练习5 这里一开始我持续的panic 最后发现好像是我写的脚本不太严谨，总之忙了一段时间还终于是写出来了 练习6与练习5的关系比较大 没费什么功夫就写出来了。

总之 万事开头难 这样看来可能练习1&2才是最难

收获

在做arceos的练习与实验的过程中 让我更立体的理解了os的设计 而且arceos Unikernel是单内核的 与linux和windos都不同，组件化的设计，没有参加这次训练营我大概不会了解到的。

认识了很多rust底层开发的语法 （大部分是跟着chatgpt老师学的，虽然有的时候它笨笨的）

学习了怎么去编写简单的脚本 shell ，makefile …… (ps:也正是缺少了这部分知识让我第二阶段的学习遇到了许多困难)

明白了一丢丢汇编代码 如何直接以地址的方式访问数据

期望

最终的任务 尝试让arceos支持linux的多应用

我的实力。。。 我真的不觉得我能写出来。。。。

但是我会去试试的 实际上已经学到许多东西了 可喜可贺

感谢

首先当然是各位老师以及助教

其次是帮助我的各位同学 希望开源社区能在大家的共同努力下越来越好

个人介绍

​ 我本人是小学教育专业的初招定向师范生。小时候受到电影黑客帝国的感染，所以对于计算机从小就很向往。但在中考完之后，由于自己天真以及父母的建议就来了师范。大学期间也由于是定向的，不能转专业。大一开始就自学计算机了，后面也参加了一些程序设计竞赛以及区域赛，在我们这个普通师范学校里面倒是打赢我们这边计算机相关专业的所有学生。但由于纯粹自己自学，学习方法上存在很大的问题，过于急功急利等原因实际上自己水平还是很差，最好的奖项也就只有蓝桥杯B组国二。在报名这个之前的项目方面的经历只写过csapp的lab，以及xv6敲了前三个lab。但也因为学习方法的问题，真正吸收到的东西很少，lab很多也是借鉴参考答案完成的。在这之前操作系统的基础只有从xv6前三个实验get到的一些东西。然后我本身对于业务方面的东西也不是很感兴趣，所以也没怎么学习这相关的。

对于这次训练营的体会

非常庆幸在当初在看群消息的时候，有群友提到了我们这个训练营。这几周的学习，我在操作系统方面还有个人的学习方法上改进了很多。在这之前我写lab的时候以及自己程序设计竞赛训练的时候，一开始的准备工作基本上都是先找到参考答案。然后在实际完成的时候会出现纠结于看不看答案的情况浪费时间，然后就是出现bug了，直接和参考答案逐行比对，而不是自己顺着代码思路找bug。这样子自己的编码和debug能力并没有提升上来，也没有体会到编程的乐趣。但这次rcore训练营没有参考答案。在第1个lab的时候，当时自己有点畏惧情绪，害怕出错。在完成了第三章的练习后，这种情绪才消减了。但在四章的学习过程中，我虽然之前写过xv6中对应的lab，但当时很多地方仍然是一知半解。在看文档的过程中，我陷入了细节的深渊。在很长的一段时间里面，我都是处于在看到这个函数的时候又想到某个问题，然后又去深究那个问题，然后在看那个问题的时候，又看到这个函数里面的细节不清楚，又去看这个函数的细节。如此反复。导致我的效率非常低下，且每一个问题都没有获得解答，看着每一个函数，脑海里面都是有点模糊，虽然脑海里面也有整体的大纲，但是对于细节来说很模糊。后面放下第四章，先去弄了第五章才意识到抽象出每个函数的接口，当看某个函数的逻辑时，对于它调用的函数里面的细节就可以暂时忽略，先有个大纲。

在实际写lab的过程中，第一个lab还比较顺利。第二个lab：在写munmap的实现的时候，因为我在实现mmap的时候是直接调用的insert_framed_area 添加了一个逻辑段，然后在memory_set中也正好看到删除以某个start_va开始的逻辑段的函数。当时就在想能不能借鉴这个函数，munmap的实现就直接删除与传入的start_va和end_va相匹配的段。但是转头一想，如果这个start_va和end_va要是在某个段中间或者是跨越多个段，那岂不是不行了。就在想办法解决这个问题。但是当时的我由于过去都是借鉴参考答案，所以当时的第一反应就是能不能找到参考答案看它有没有想这么多。有点害怕自己去尝试，然后这个感觉代码量也有点大。但后面发现测试样例很简单，就没考虑那么多。但是这里我还没有克服自己内心的障碍，因为我当时还是去借鉴了其他人的仓库（当时意外得知还可以这样干），来确定自己的想法。但是在实现第三个lab的时候：我算是克服了自己的这一内心障碍。当时自己写完之后，一make test就报time out了，当时的第一反应也是参考答案借鉴。但这次我坚持自己debug，最后花了一天半的时间找到了这个bug，仅仅只是一个地方少了一行代码。就是sys_spawn系统调用里面没有运行add_task函数, 导致一直运行的时候timeout. 就一行代码差不多两天半时间. 还是通过逐行和最开始能运行起来的ch5分支的代码进行比对才找到. 之前一直都找错方向了, 没有想到是测试样例调用了sys_spawn出的错误. 然后调bug的时候还遇到了一个问题, 当我直接用checkout回到ch5的初始提交记录的时候, 它在os文件夹里面make run的时候会报链接出错. 这个也花了好长时间去找原因, 但最后还是没有找到. 最后是通过直接重新clone仓库, 然后把初始ch5里面的文件复制过来才成功. 当找完bug，所以test全部通过的那一刻，内心确实是挺激动。但如果是放在以前的话，我花了一天半结果就这么一行代码，别说激动了，在自己内心没把自己pua死已经算好的了，也正是因为这种急功近利的心态，自己过去也是疯狂参考答案，但参考完答案之后，又由于不完全是自己写的，其实内心也还是会内耗，觉得这玩意没弄一样。但这次至少还是感觉挺有成就感，算是克服了内心的一重障碍，并且这种不借鉴答案的学习方式让我对于知识点本身的理解，以及自己内心的舒服程度上升了很多很多，至少不会内耗了。

这次rcore算是我真正意义上的入门lab。在完成这三个lab的过程中，我的完成速度再不断的加快，现在正在弄的第四个lab已经感觉比较得心应手了。之后也可以更加从容的面对其他lab。

然后rcore训练营，本身也是一份非常非常nice的操作系统学习手册，让我对于操作系统的各个部分的认识也上了一层楼。

rust 这门语言给我最大的感触就是它安全性，基本上所有可能出现的错误都帮你报错了，只要运行通过了很大程度上就不会有很大的问题，有也是逻辑上的问题了，不像c语言的指针，头大大的。然后它Option对于错误处理也非常nice。以及它的trait写起来很舒适，我在这之前并没有写过什么面向对象的项目，所以对于这个的认识可能也不是很深。

这次由于本专业要去小学实习，在加上自己的拖拉, 生病，以及一系列问题，就导致知道现在才完成了。希望还有机会能够第三阶段及格。加油.

总结报告

逐练习报告

练习1：获取镜像大小，使loader能够根据对应信息能够自动识别文件大小

main 函数中，固定设置 app_size = 32，这个显然是不合理甚至危险的。
请为 image 设计一个头结构，包含应用的长度信息，loader 在加载应用时获取它的实际大小。

一开始想要尝试类似于rcore中在链接脚本的特定位置保存数据并且通过build.rs脚本获取对应镜像大小然后再写入到链接文件中去的方法。

后面想到这个方法会因为相互依赖问题而不容易解决，最原初的设想在于类似rCore的处理方案，在原初的链接脚本中保存一个位置用于存储应用程序大小，后面在loader中对于这个段的数据进行获取，但是这部操作实际上是需要在链接的时候完成的，即我还不知道最终生成的二进制文件的大小就要将其写入进去。（后面想了下可能还可以在外面手动修改这个段，但是有点麻烦了就没有使用）。

在与邝劲强同学进行沟通的时候，发现其实可以用相对来说更加简单的方法来实现这个效果，即通过一个脚本实现了对于镜像文件大小的获取以及自动将代表对应文件大小的bin文件加载到对应的位置。这个地方特别感谢邝劲强同学分享的有关 dd 会相互覆盖，可以使用 seek 跳过一段的信息。

1
2
3
4
5
6
7
8
9
10

APP_BIN_SIZE=$(stat -c%s "./hello_app.bin")
echo $APP_BIN_SIZE
printf "%04x" $APP_BIN_SIZE | xxd -r -p > ./size.bin

# Using Zero to fill the block to 32M(32Times, one times for 1M)
dd if=/dev/zero of=./apps.bin bs=1M count=32
# Add origin app into the end of the file (not cover)
dd if=./size.bin of=./apps.bin conv=notrunc       bs=1B seek=2
dd if=./hello_app.bin of=./apps.bin conv=notrunc  bs=1B seek=4
mv $BASE_DIR/hello_app/apps.bin "$BASE_DIR/apps.bin"

练习2： 拓展image头结构，使之可包含两个应用。

通过对于 hello_app 的简单拷贝，可以实现第二个应用，这一步主要是在一开始的基础上拓展了头结构，但是由于这里没有提供对于更多应用程序的支持以及通过函数返回了文件大小埋了个坑（后面会提到）。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# Input: The Name of Directory
# Output: The size of the binary image
function generateBinrary() {
  # Create Binrary
  echo $1
  cd "$BASE_DIR/$1"
  echo `pwd`
  cargo build --target riscv64gc-unknown-none-elf --release
  # remove symbol information
  rust-objcopy --binary-architecture=riscv64 --strip-all -O binary ../../target/riscv64gc-unknown-none-elf/release/$1 ./$1.bin

  # return size
  return $(stat -c%s "./$1.bin")
}

cd $BASE_DIR
hex1=$(printf "%02x" $hello_app_size)
hex2=$(printf "%02x" $hello_ebreak_size)
hex="$hex1$hex2"
echo -n $hex | xxd -r -p > size.bin

练习3：批处理形式运行两个单行代码应用 nop 和 wfi

这里有个小问题就是需要修改原始代码中给出的 -> ! 和 options(noreturn) 标志，以避免出现没有办法返回的情况。

这个地方实际上实现的批处理并不是真正意义上的批处理，我在复用之前代码的时候出错了，这个问题在 lab2.5-commit 中得到了修复。

以下是当时提交的实现，基本上就是对之前的代码的直接复用。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

let apps_start = PLASH_START as *const u8;
let byte = unsafe {
  core::slice::from_raw_parts(apps_start, size_of::<u16>())
};
let app_size_1 = u8::from_be_bytes([byte[0]]);
let app_size_2 = u8::from_be_bytes([byte[1]]);
println!("size 1: {app_size_1}, size 2: {app_size_2}");

println!("Load payload ...");

println!("sizeByte: {byte:?}");

let read_only_app1 = unsafe {
  core::slice::from_raw_parts(apps_start.offset(size_of::<u16>() as isize),
  app_size_1 as usize
)};
let read_only_app2 = unsafe {
  core::slice::from_raw_parts(apps_start.offset((size_of::<u16>() + app_size_1 as usize) as isize),
  app_size_2 as usize
)};

// println!("content: {:?}: ", code);
println!("Load payload ok!");

println!("Copy app ...");
let load_start = LOAD_START as *const u8;

// load app 1
let load_app_1 = unsafe {
  core::slice::from_raw_parts_mut(load_start as *mut u8, app_size_1 as usize)
};
let load_app_2 = unsafe {
  core::slice::from_raw_parts_mut(
    load_start.offset(app_size_1 as isize) as *mut u8, 
    app_size_2 as usize)
};

// Copy App Data From ReadOnly Areas
load_app_1.copy_from_slice(read_only_app1);
load_app_2.copy_from_slice(read_only_app2);

练习4：实现 SYS_TERMINATE

这个练习没什么好说的，直接添加 arceos_api 然后再加到符号表里面实现一下功能就可以了

1
2
3
4

fn abi_terminate() -> ! {
    println!("[ABI:TERMINATE]: Shutting Down !!!");
    arceos_api::sys::ax_terminate();
}

练习5：改造应用 hello_app

在完成实验五的时候主要出现了几个超出意料而且有点摸不着头脑的情况，包括但不限于a7寄存器被修改，莫名其妙的镜像文件截断，主要的修复细节可以参考 批处理修复，多道程序支持，返回值错误修复，拷贝错误修复，寄存器错误修复 等具体 commit。

本任务的主体部分实际上与之前的exec2.4没有什么特别的差异，主要的难点在于puts的实现实际上调用了迭代器的功能，同时这还牵涉到由于字符串实现中&str的链接问题。

1.由于在操作中使用了字符串，但是字符串被放置在rodata段，在默认链接情况下rodata段实际上位于.text段前面，这会违背我们以装载地址作为应用的起始运行地址的想法（jalr LOAD_ADDRESS）【在起始部分有一大串0】

因此，需要手动实现一个类似的链接脚本（本处直接采用了rCore之前使用的链接脚本进行替代），添加build.rs编译脚本，给cargo添加了rust-args参数以选择我们自己做的链接脚本对于hello_app包进行链接。此处特别鸣谢赫森同学在群里分享的有关信息。

2.在修改了链接脚本之后仍然会出现神奇的报错信息，经过修改 MakeFile 运行 debug 之后发生产生这个情况的原因在于程序的二进制文件被异常截断了，同时出现很神奇的文件大小不增反减的情况（如下图）。

这跟我之前exec2.2实现的那个函数有直接的关联，或者说主要的问题就处在我使用的这个函数这里。

1
2
3
4
5
6
7
8
9
10
11

# exec 2.2 实现的函数
function generateBinrary() {
  # Create Binrary
  echo $1
  cd "$BASE_DIR/$1"
  cargo build --target riscv64gc-unknown-none-elf --release
  rust-objcopy --binary-architecture=riscv64 --strip-all -O binary ../../target/riscv64gc-unknown-none-elf/release/$1 ./$1.bin

  # return size
  return $(stat -c%s "./$1.bin")
}

王瑞康同学指出我的脚本代码中实际存在缺陷，问题主要出在我这个地方是通过bash函数的返回值来实现对于镜像文件大小的获取，但是实际上这个地方由于bash函数返回值限制在0~255位， 当添加了&str之后的镜像文件大小实际上达到了将近4110，则会面临取模截断的情况，在这样情况下4110 % 256 = 13 最终导致了实际上只有13个字节的数据被成功加载到内存中来，最终导致了代码出现异常的截断情况。

针对于这个情况，主要修复的方案在于通过echo + result=${}，外加事先转换成为十六进制。

1
2
3
4
5
6
7
8
9
10
11
12

# Input: The Name of Directory
# Output: Hex Size of Binary 
function generateBinary() {
  # echo "====================" $1 "===================="
  # Create Binrary
  cd "$BASE_DIR/$1"
  cargo build --target riscv64gc-unknown-none-elf --release
  # remove symbol information
  rust-objcopy --binary-architecture=riscv64 --strip-all -O binary ../../target/riscv64gc-unknown-none-elf/release/$1 ./$1.bin

  echo "$(stat -c%s "./$1.bin" | xargs printf "%04x")"
}

3. 在调试完成上述问题之后发现，在当前情况下仍然出现了 panic，经过调试之后发现，主要问题出现在 a7 寄存器被擦写。

针对于这个问题，在之前的练习四多次调用同一个函数的时候也回出现类似的错误，当时进行修复的主要是在函数调用末尾添加了unsafe { core::arch::asm!("ld a7, {}), sym ABI_TABLE}，在每一个可能使用到 a7 寄存器的地方手动添加一次寄存器，但是在使用迭代器的情况下，这种简单的处理方法并不奏效。根据群里面王瑞康同学分享的clobber_abi("C")，在应用程序调用asm的时候添加了这个操作就可以保持寄存器不变。

练习5：代码重构

练习五的时候由于接受了赫森和邝劲强同学有关于当前脚本不能很好的适应多道程序加载的建议（裱糊匠操作太多），对于原先的脚本进行了重构，重构后仅需要以字符串形式在脚本中添加对应的应用名称，就可以自动将应用生成二进制文件放到一起。

1
2
3
4
5

// 注：这个地方实际上搞错了PFLASH的具体位置，但是懒得改了
# PFLASH 32M ]
# PFLASH 32M ] [ NUM_OF_IMAGE ]
# PFLASH 32M ] [    u16:2B    ] [ BYTE_LIST:4B*NUM_OF_IMAGE ] 
# PFLASH 32M ] [     2B + 4B * NUM_OF_IMAGE                 ] [  ] [  ] [  ]

这段主要实现的交过类似于前文中所实现的，具体包括生成应用程序脚本并且通过objcopy去除其中非必要的信息，通过echo的方式传递对应的数据。
用下文中的for循环包裹上面的这个函数，实现了将对应的app_name, app_size等数据保存在bash一维数组中的效果（方便后文调用）

1
2
3
4
5
6
7

for name in "${app_names[@]}"; do
  echo name: $name
  app_size=$(generateBinary $name)
  app_sizes["$name"]=$app_size
  link+=${app_size}
  NUM_OF_IMAGE=$(expr $NUM_OF_IMAGE + 1)
done

根据上面获取到的对应size信息，自动生成有关于num和size的数据，并且分别生成十六进制二进制文件合并到原先的PFALSH空间中。

1
2
3
4
5
6
7
8

cd $BASE_DIR
printf "%02x" $NUM_OF_IMAGE | xxd -r -p >num.bin # NOTE: not allow app > 255
echo -n "${app_sizes[@]}" | xxd -r -p > size.bin
echo "size.bin size: $(stat -c%s "./size.bin")"

dd if=/dev/zero   of=./apps.bin              bs=1M count=32
dd if=./num.bin   of=./apps.bin conv=notrunc 
dd if=./size.bin  of=./apps.bin conv=notrunc bs=1B seek=2

然后，根据上文中保存的对应数据，自动生成其他的，涵盖包信息的二进制文件，并且逐个合并到前面的空间中。

1
2
3
4
5
6
7
8

start_offset=$((2 + 4 * $NUM_OF_IMAGE)) # NUM_OF_IMAGE:2B + IMAGE_SIZE:4B * NUM_OF_IMAGE
echo "start_offset" $start_offset
for ((i=0; i<${#app_names[@]}; i++)); do
  app_name=${app_names[i]}
  app_size=${app_sizes[i]}
  dd if="$BASE_DIR/$app_name/$app_name.bin" of=./apps.bin conv=notrunc bs=1B seek=$start_offset
  start_offset=$((start_offset + app_size))
done

在loader中，主要做出了如下改变：

首先，根据当前的二进制布局，获取app_num作为总应用程序数量研判标准，获取对应各个应用程序sizes的区域

let byte_num = unsafe { core::slice::from_raw_parts(apps_start, size_of::()) };
let app_num = u8::from_be_bytes([byte_num[0]]);

保存操作如下：

其中需要特别注意到的是由于rust中的自动union操作（忘记叫啥名了，就是自动对齐），会对于u8,u16连续的情况下在u8之后补零

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

// Gain Each App Size
let mut apps: [APP; MAX_APP_NUM] = [APP::empty(); MAX_APP_NUM];
let byte_apps_sizes = unsafe {
    // NOTE: BC Rust Internal structure autocomplete will fill vacancy, thus u16 rather than u8
    core::slice::from_raw_parts(
        apps_start.offset(size_of::<u16>() as isize),
        app_num as usize * size_of::<u16>(),
    )
};

let mut head_offset = size_of::<u16>() + app_num as usize * size_of::<u32>();
for i in 0..app_num {
    let i = i as usize;
    apps[i] = unsafe {
        APP::new(
            apps_start.offset(head_offset as isize),
            u16::from_be_bytes([byte_apps_sizes[i * 2], byte_apps_sizes[i * 2 + 1]]) as usize,
        )
    };
    head_offset += apps[i].size;
}

并且将其存储到结构体数组中：
结构体实现如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

#[derive(Clone, Copy)]
struct APP {
    pub start_addr: *const u8,
    pub size: usize,
}

impl APP {
    pub fn new(start_addr: *const u8, size: usize) -> Self {
        Self { start_addr, size }
    }
    pub fn empty() -> Self {
        Self {
            start_addr: 0xdead as *const u8,
            size: 0,
        }
    }
}

impl core::fmt::Debug for APP {
    fn fmt(&self, f: &mut core::fmt::Formatter<'_>) -> core::fmt::Result {
        if self.size == 0 {
            return Ok(());
        }

        f.debug_struct("APP")
            .field("start_addr", &self.start_addr)
            .field("size", &self.size)
            .finish()
    }
}

最后通过一个for循环实现重复装载应用程序到指定地址

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

// LOAD APPLICATION
for i in 0..app_num {
    println!("====================");
    println!("= START OF APP {i} =");
    println!("====================");
    let i = i as usize;
    let read_only_app =
        unsafe { core::slice::from_raw_parts(apps[i].start_addr, apps[i].size) };
    let load_app =
        unsafe { core::slice::from_raw_parts_mut(load_start as *mut u8, apps[i].size) };
    println!(
        "Copy App {i} data from {:x} into {:x}",
        apps[i].start_addr as usize, LOAD_START
    );

    load_app.copy_from_slice(read_only_app);

    trace!("Original App: ");
    trace!("{i}: {read_only_app:?}");

    trace!("Load App:");
    trace!("{i}: {load_app:?}");

    register_abi(SYS_HELLO, abi_hello as usize);
    register_abi(SYS_PUTCHAR, abi_putchar as usize);
    register_abi(SYS_TERMINATE, abi_terminate as usize);

    println!("Executing App {i}");
    let arg0 = b'c';
    unsafe {
        core::arch::asm!("
        la      a7, {abi_table}
        li      t2, {run_start}
        jalr    t2",
            clobber_abi("C"),
            run_start = const LOAD_START,
            abi_table = sym ABI_TABLE,
        )
    }

    println!("APP {i} FINISH !!!")
}

练习6：应用虚拟空间

基本上没什么好说的，对于base2.5的代码进行简单复用就可以实现。