make run on master branch, and it panicked with:

Exception(StorePageFault) va = 0xffffffffffffffe8 instruction = 0x1acfe
panicked at 'page fault!', src/interrupt.rs:76:5

• rust-toolchain = nightly-2020-06-04
• riscv = 21e32ee In the meanwhile, multicore branch worked normally 15 days ago, but now it failed with page fault too. Given that the only change of it in the last two weeks was the update of riscv crate, so I think there maybe some bugs in it. Actually, I made it work again by rolling back the riscv version to c62af46.

Following the step of @wangrunji0408, I want to port the tutorial from Qemu to K210, a RISC-V board which is cheap and simple, as an important part of the fourth edition of tutorial. K210 is based on RISC-V spec 1.9.1, which was published about 4 years ago. So you can hardly find a toolchain or bootloader that fits it perfectly now. For example, OpenSBI 0.4/0.8 don't work normally on K210... About 1 year and a half ago, rjgg tried to port rCore to K210 and succeed in the end. Here is his log. He modified OpenSBI 0.3 in order to support K210, you can find that version here. How to use it to completing porting? It is at a relative ease. First, download the modified OpenSBI, and change the FW_PAYLOAD_ALIGN to 0x200000 since we want to put our kernel to 0x80200000 on memory. Then, merge the OpenSBI image(fw_payload.bin) and our kernel image into a big one using dd tool and finally burn it into flash. Now, chapter 2 can run on K210 successfully. I will create a new branch about porting later.

Sometimes kernel panicked when typing commands in the user shell, the following two errors could be found in the panic infomation:

panicked at 'called `Option::unwrap()` on a `None` value', src/process/processor.rs:100:40
panicked at 'thread not exist!', src/process/thread_pool.rs:49:31

Maybe there are some bugs in the scheduling module or the thread management module.

Replace asm! with llvm_asm!

And fix some clippy issues, but still have some issues for now. I will fix it after this PR and add fmt and clippy CI check.

The println!("message received in child process = {}", string); will print ^@ (ascii 0, '\0') as well. The implement of print a Rust string should print all the bytes but not stop until \0.

Normally the terminal will not display the ^@, but actually it has been written into stdout. But, What's more, the command less will display it. If we write a simple Rust program like this:

fn main() {
    let mut string = String::from("");
    string.push('A');
    string.push('\0');
    string.push('\0');
    println!("{}", string);
}

and run cargo run, it will display A. But if we use cargo run | less, it will display A^@^@.

So if we use less in the test script to show the result, we should not write '\0' into the stdout (actually alloc::string::String is just a vec<u8> and normally will not contain '\0'). Or it will make a confusing display to the students, students will use meaningless time to debug why there's ^@. (macOS terminal displays ^@, some terminal will display something messy like default terminal of Ubuntu)

Here, I change the script for not display '\0', but keep the transfer of the '\0' in pipe as the end of transfer.

现在版本的build.rs存在这样的问题：在不改变USER_IMG环境变量的前提下，更新usr/build下的用户程序.img，并不能使得内核镜像中的用户程序一起更新。这是因为build.rs生成的link_user.S本身没有发生改变，按照Rust增量更新机制，打包进可执行文件的数据也不会变。如果在生成代码时加入与编译时间有关的信息，就可以解决这一问题。

参考之前在step_by_step项目中的做法，添加了新的Makefile 运行make docker将会查看本地是否存在镜像panqinglin/tutorial，不存在则从远端拉取，运行docker镜像之后将当前代码目录挂载到镜像内的/mnt目录 同时支持自己修改Dockerfile来修改docker镜像内容，默认情况下make build_docker将在本地生成panqinglin/tutorial镜像，与云端一致。

The commit id (c611248) of rcore-fs-fuse installed by cargo in usr/Makefile isn't match the commit id (d8d61190) of rcore-fs rcore-fs-sfs in os/Cargo.toml.

So, got the error running messages:

available programs in rust/ are: panicked at 'failed to open SFS: WrongFs', src/libcore/result.rs:1189:5

You need to delete ~/.cargo/bin/rcore-fs-fuse, and rebuild rcore-fs-fuse by 'make rcore-fs-fuse', then 'make user_img'

The commit id (c611248) of rcore-fs-fuse installed by cargo in usr/Makefile  isn't match the commit id (d8d61190) of rcore-fs rcore-fs-sfs in os/Cargo.toml.

So, got the error running messages:

available programs in rust/ are:
panicked at 'failed to open SFS: WrongFs', src/libcore/result.rs:1189:5

You need to delete ~/.cargo/bin/rcore-fs-fuse, and rebuild rcore-fs-fuse by 'make rcore-fs-fuse', then 'make user_img'