这是我关于rCore的学习文档
八月
- Day 30 (2020-08-03)
- Day 31 (2020-08-04)
- Day 32 (2020-08-05)
- Day 33 (2020-08-06)
- Day 34 (2020-08-07)
- Day 35 (2020-08-08)
- Day 36 (2020-08-09)
- Day 37 (2020-08-10)
- Day 38 (2020-08-11)
- Day 39 (2020-08-12)
- Day 40 (2020-08-13)
- Day 41 (2020-08-14)
- Day 42 (2020-08-15)
- Day 43 (2020-08-16)
- Day 44 (2020-08-17)
- Day 45 (2020-08-18)
- Day 46 (2020-08-19)
- Day 47 (2020-08-20)
- Day 48 (2020-08-21)
- Day 49 (2020-08-22)
- Day 50 (2020-08-23)
- Day 51 (2020-08-24)
- Day 52 (2020-08-25)
- Day 53 (2020-08-26)
- Day 54 (2020-08-27)
七月
- Day 1 (2020-07-02)
- Day 2 (2020-07-03)
- Day 3 (2020-07-04)
- Day 4 (2020-07-05)
- Day 5 (2020-07-06)
- Day 6 (2020-07-07)
- Day 7~9 (2020-07-08)
- Day 10 (2020-07-11)
- Day 11 (2020-07-12)
- Day 12 (2020-07-13)
- Day 13 (2020-07-14)
- Day 14 (2020-07-15)
- Day 15 (2020-07-16)
- Day 16 (2020-07-17)
- Day 17 (2020-07-18)
- Day 18 (2020-07-19)
- Day 19 (2020-07-20)
- Day 20 (2020-07-21)
- Day 21 (2020-07-22)
- Day 22 (2020-07-23)
- Day 23 (2020-07-24)
- Day 24 (2020-07-25)
- Day 25 (2020-07-26)
- Day 26 (2020-07-27)
- Day 27 (2020-07-28)
- Day 28 (2020-07-29)
- Day 29 (2020-07-31)
1、通过阅读 Rust by Example学习基础语法
2、阅读部分Rust编程之道
3、做一些编程题
1、<<通过例子学Rust>> 看到了闭包 有些卡住了 trait的含义没有理解 明天通过<<rust编程之道>>好好研究一下
2、前面的有些概念与之前学过的语言截然不同，思维的转变需要一些时间
3、没有开始做编程题，还需要理论的巩固
1、完成基础语法的学习
2、将<<Rust编程之道>>上的章节仔细研究下
3、完成一部分编程题
1、完成了基本语法的学习,对rust有了一个直观的认识
2、仔细阅读了<<rust 编程之道>>第三章,从抽象类型开始就晕了,有点搞不清楚原理，看来得做一些题练一下了
3、解决了昨天的一些疑惑,晚上要准备期末考试了😭
1、完成第四章第五章的阅读
2、整理昨天的问题
因为今天考试了 所以进度不太理想-- 😭
1、基本完成了第四章第五章的阅读，但是并没有完全吃透，还需要多读几遍，好书不厌百回读啊
2、把昨天的问题基本都搞明白了
3、所有权还真是个好东西，就是生命周期有点绕
1、完成编程rustling上的程序题，对所学知识进行巩固
2、第九、十、十三章的内容稍微往后放一下
1、小练习基本都完成了，还有个别的存在一些问题
2、rust编程之道上的 unsafe还没有看 其他的都看的差不多了 多写多练就行了
3、之前看的好多都忘了 还需要更多的记忆
1、将rustling上存在的问题解决
2、准备看笨方法学c语言
3、看unsafe块的讲解
4、将之前所看知识再看一遍 记一下
今天啥也没搞 一直在弄期末 /(ㄒoㄒ)/~~ 这两天考试太多了 需要暂时放慢进度了
完成昨天的计划
1、看了unsafe
2、订下了要做的习题
夺命连环考试 /(ㄒoㄒ)/~~ 接下来几天努力赶进度
1、将令狐一冲的视频刷一遍
2、将剩下的习题做完
1、令狐一冲基础过了一遍
2、剩下的习题基本做完
1、将令狐一冲的进阶版选择一部分看
2、将剩下的习题做完
3、开始笨方法学C语言
1、令狐一冲进阶看了一部分
2、rustling做完
1、做leetcode上的题 大概2~3道
2、看一遍riscv
3、看一下lab
1、做了两道题
2、riscv大概看了一下
3、lab0弄了一部分
1、做leetcode上的题 大概2~3道
2、看一遍riscv
3、看一下lab
1、没有做题 打算先搞lab
2、riscv特权看完了
3、环境配置完毕 lab0做完 lab1看了一遍
1、做lab1
2、看lab2
3、leetcode的题等到之后再做
1、lab0写了实验报告 还有一些小问题
2、lab1做了一部分
1、将lab0小问题解决
2、写lab1实验报告
3、预习lab2
1、lab0残留一些没什么影响的问题 留到实验之后解决
2、lab1实验报告 √
3、预习lab2 √
1、写lab2实验报告
2、完成一部分lab2实验题
3、预习lab3
实验二感觉需要一定的时间--
1、完成lab2实验题
2、预习lab3
1、实验二大致理清楚了
2、线段树算法写了80% 打算先做实验三
1、完成lab3
1、lab3感觉很晕 今天有点小事情 所以没什么进展
1、完成lab3
2、lab3基本完成 不过那个汇编我是真没看懂-- 仔细琢磨下！
1、学习lab4
重新看了点汇编的知识，并且将整个lab4过了一遍
感觉最近很浮躁，不是很能看下去，研究fpga吗?
1、做lab4习题
做了一部分习题
最后还是决定去研究rcore的移植，目前是一头雾水
研究fpga移植
自己终于把lab4搞出来了，这个文档简直劝退。。。 而且lab5好像也是。。。 不过起码把lab4搞明白了 lab4->lab5好像还要修改线程 吐了啊
fpga今天没有来得及看
完成线段树以及线程的习题
基本都完成了 但是fork那里还有点问题
线段树之前想的太复杂了 现在改成一次分配一个内存空间 很容易就解决了
调度算法也有点坑。。。 最后在Thread.rs加了优先级属性才好一点
完成lab5、lab6 以及习题
习题基本都完成了 还有些拓展的习题没有做，留到明天做一部分，今天因为clone的原因 琢磨了半天。。。
完成一部分拓展习题 将docx改成md格式 并且将实验文件夹上传
研究了半天置换算法，卡在了给时钟算法标记sign的地方。。。下午把总结报告写了些，格式弄了下，暂时告一段落了，明天歇一天！
暂时休息一天
结果还是没闲住，把置换算法给写了，明天就要找回状态了
1 看一下zcore
2 研究fpga
稍微看了下，有点其他的事情，就没怎么多看
1 看一下zcore
2 研究fpga
fpga没有找到很好的教程，对于移植还是一头雾水
1 重新看一下rust 将语法总结一遍
对rust理解多了些 可能有利于之后的学习
从 8-1到8-3没干什么事情。。我觉得我需要反省下，今日在向老师的指导下初步分了组
我选的是k210移植方向，一直对这个感兴趣，希望能在这个方向做点成果吧，单核上跑rCore肯定是要弄的，至于多核，看之后的时间安排吧
今天的日程是国科大的团队进行报告，在复现吴一凡学长的lab2项目中出现了神奇的bug
发现在ubuntu上无法跑，但是在wsl中能够跑，很神奇。。
尝试复现 更换riscv的指令集从 imac->gc 发现可以跑了 但是怎么会跟指令集有关系呢？
之后查看汇编内容 发现stack居然在bss段中。。然后将stack清了 怪不得报错
更改了内容之后可以顺利的跑起来了
今天的日程是
去清华伯努利参观并参加报告
在向老师的指导下细化了研究方向，打算继续搞rCore-Tutorial 尝试复现lab3 发现有很多问题。。慢慢搞吧
这里是我的rCore移植的地址： https://github.com/freheit889/rCore-Tutorial
在大页表建立过之后，尝试将mapping加入其中，进行内核的重映射。 在确认无语法错误之后，测试在k210上输出
输出错误
virtual address is already mapped
尝试找出错误，发现在kernel_end到memory_end之间的地址空间已经被映射? 很神奇
更细化的找出问题 在map中
0xffffffff8013c
0xffffffff8013c
这个地址出现了两次??? 最后发现是在linker.ld中在kernel_end之前没有对齐
加上. = ALIGN(4K);就没有这个bug了
之后在activate报错 后来发现1.9版本中没有mtval寄存器 我们需要将异常处理的代码在opensbi中进行处理 在opensbi中加入一些代码
uintptr_t epc = csr_read(CSR_MEPC) - 0xffffffff80000000u + 0x80000000u;
ulong insn = *(uint32_t*)epc;
就可以跑通了！
出现了 InstructionFault 现在要找下问题的原因
改了下 entry.asm 发现出现了其他的问题
sbi_trap_error: hart0: misaligned store handler failed (error -10)
sbi_trap_error: hart0: mcause=0x0000000000000006 mtval=0xffffffff80029274
sbi_trap_error: hart0: mepc=0xffffffff80027d94 mstatus=0x0000000000000820
sbi_trap_error: hart0: ra=0x4605122861142ea5 sp=0xffffffff80029254
sbi_trap_error: hart0: gp=0x80e7ffffc0974701 tp=0x00971228a009bc40
sbi_trap_error: hart0: s0=0xef2a1308f32ad725 s1=0x0000b61724a13823
sbi_trap_error: hart0: a0=0x85b2e8aeb9860613 a1=0x2a4080e7fffff097
sbi_trap_error: hart0: a2=0x6526a009e0aee4aa a3=0xd617eb2e6586e72a
sbi_trap_error: hart0: a4=0x621c326606130000 a5=0x4705033446090aa8
sbi_trap_error: hart0: a6=0xc0977862fc3a65c6 a7=0xa009b32080e7ffff
sbi_trap_error: hart0: s2=0x80e7000000970aa8 s3=0x0000d517a00972c0
sbi_trap_error: hart0: s4=0xa517610c33050513 s5=0x8131d06505130019
sbi_trap_error: hart0: s6=0x3c23f7aa1b88fbaa s7=0x06130000b61724a1
sbi_trap_error: hart0: s8=0xf09785b2f82eb2a6 s9=0xf42a236080e7ffff
sbi_trap_error: hart0: s10=0xefaa7522a009f02e s11=0x0000d617f3ae7582
sbi_trap_error: hart0: t0=0xa009798080e70000 t1=0x324505130000d517
sbi_trap_error: hart0: t2=0x05130019a517610c t3=0x1328621c2b860613
sbi_trap_error: hart0: t4=0x75c247050bb44609 t5=0xffffc0976862ec3a
sbi_trap_error: hart0: t6=0x1328a009ac4080e7
后来发现是因为hanler里没有处理好
之后可以开始进行线程，当线程数大于2 就会出现
virtual address is already mapped
当线程数等于1 就会出现
Thread {
thread_id: 0x2,
stack: Range {
start: VirtualAddress(
0x1000000,
),
end: VirtualAddress(
0x1008000,
),
},
context: None,
} terminated: unimplemented interrupt type
cause: Exception(StoreFault), stval: 1007ff8
果然是内存分配 之前在qemu中 所有的内存都是可用的，但是在k210中 一些内存空间是用不了的，之后将线程分配内存放在可用空间内，可以跑起来一个线程，但是在多线程时还是会产生问题
virtual address is already mapped
这是为什么？不是有重叠区域检测吗
在range.rs中 判断重叠是这样的
self.start.into() < other.end.into() && self.end.into() > other.start.into()
在k210的移植中修改为<=即解决了当前的问题，但是尝试在qemu中复现没有这个问题了?那么神奇的吗
可以尝试开始lab5了 但是lab5跟lab6一般是在一起的 可能要一块搞了 Lab5中的设备树 对于块设备驱动 我还不是很了解，可能需要看一下k210的手册?
读取设备树 起始物理地址居然是0 ??? 可能要到opensbi中找一下原因 是不是因为没有读取dtb文件?
找到问题了 是因为没有将设备树的地址正确放在内核中 修改opensbi中的
内容xxxxx 可以读出正确内容了!
FW_PAYLOAD_FDT_ADDR=0x80300000
但是我们现在并不需要用到虚拟块存储 所以我们需要对drivers进行一些修改
因为我们现在并没有flash驱动 所以我们需要将用户镜像加载到内核中
利用吴一凡学长已经进行过的工作，我们将用户镜像加载入kernel中，
之后我们会进行elf的读取
试了一下 感觉需要修改的东西很多 可能难度不会下于给k210写flash驱动。。。
那就写驱动吧
尝试了k210给的demo flash可以正确的使用 之后就可以考虑将其改写为Rust 重新看一下rCore的驱动实现
昨天从深圳回来。。感觉有点累 歇了一天
尝试将C语言的驱动移植到rust
1 将rCore的驱动搞明白
2 将C语言flash驱动看一下
我觉得我应该首先实现读flash 然后尝试写
首先是对驱动的抽象，然后进一步抽象具体的驱动，调用对应设备的驱动，实现 读取或者写入
我对驱动的开发还没有完整的概念 决定从<<Linux驱动开发与实战>>这本书入手
看了一会 了解了下基本概念，开始看k210的实例flash程序
发现opensbi中并没有关于spi的支持，重新实现spi过于复杂 问了下学长，学长建议
可以试试能不能将 k210官方支持的sdk加入到opensbi中 然后在rCore进行调用，
可以尝试下这个方向
尝试将sdk的文件弄到opensbi中 现在有个问题 我怎么用它
研究了下 还是没有什么头绪 我觉得我应该将opensbi搞明白 以及 rCore是如何调用opensbi这一关键搞清楚 不然我都不知道自己在做啥
如果这一步可以实现 则SD卡的驱动也能很快搞定
- 搞明白rCore是如何调用的opensbi
- 尝试将SDK加入到opensbi中，实现较为简单的读写
难道我要通过ecall来实现读写flash吗?仔细一想可能也是可行的
这样吧 我先实现系统调用的读命令 提前将文件写入 测试能不能读出来
跟学长沟通了下，尽量想不以系统调用的方式来解决这个问题 所以实现spi应该是
必须的了，或者说我要开始研究多核？但是好像也不比flash简单多少 难顶啊
找了一大圈 发现居然有rust的spi库
https://github.com/rust-embedded/embedded-hal
链接在这 太强了吧
我接下来的任务就是研究这个库 争取早日用上
研究SD卡历程，尝试将例程改写为flash
遇到了一些困难 对一些函数不太理解
目前进度
1、 write与read基本函数写了
2、 对于cmd的操作有点不太明白
3、 大致思路已经理清 争取明天搞定！
第一个问题：逆向推导出的spi 没有关于cmd的操作 我想我应该在spi.rs中加进去
尝试一个最简单的输出函数，结果有意想不到的错误。。。
sbi_emulate_csr_read: hartid0: invalid csr_num=0x300
是因为跟opensbi有冲突?
查了下手册，发现csr_num=0x300表示的是m态的csr
spi只能工作在m态?查了下库，发现有这样一段代码
let mstatus = mstatus::read();
果然是读了m态的寄存器，但是问题来了，我该怎么做?
我看了下相关的库，确实是在裸机模式下进行访问的，所以我怎么通过opensbi来操作它呢
因为我这里默认是从0x80000000,但是访问的地址在这个之前，有点迷茫
更换了访问用户程序的方式 现在是将镜像链接在kernel里,但是k210的内存也太小了,动不动就alloc error 。。。
具体的方式是将k210 memory抽象为device 这样对第三版的改动很少，是能接受的范围
这里的设备树被我提前去除了，所以并不会对内核产生影响
data_start=0xffffffff80066000
bss_start=0xffffffff8021f000
start address =0xffffffff80066000 end address=0Xffffffff8021ef38
修改了一下堆大小，现在fs::init没问题了 但是有了新的问题
Alloc error 我起初一直以为是堆的大小不合适，后来发现内核线程可以跑，那用户线程不可能不行吧？最后发现错误在这一行
let mut buffer = Vec::with_capacity(size);
我的天，内存不够用。。。。。。难受死我了
这咋搞?搞SD卡吗，我太难了。
最后我发现了问题所在，因为我们在内存里面还模拟了一块block 这样就是 1.8+1.8+1.2=4.8M 所以内存才会不够用 现在问题是 怎么才能在尽量小内存的情况下完成这件事呢?
问了下洛佳大佬 大佬建议我用 release 这样会减少一半的内存 确实可行！之前一直没有想到，太强了!
现在可以烧进去了 但是有个问题 怎么没有输出?很奇怪
尝试将用户态的堆大小改为100K，之前是1M。。。有点夸张
又发生了bug 一直提示我有非法的指令异常。。。？？？
尝试输出了下 结果程序入口点是非法的 这怎么可能。。我在qemu上测试的没有错误。。。
确实是程序入口点出了问题，之前并没有考虑到内存的问题，现在多了用户内存之后，我们必须将一段内核内存给用户使用，我将0xffffffff05000000之后的内存分配给elf,然后试图访问在0xffffffff05000000上访问入口点，然后。。卡死了
对我来说已经是个好消息了，起码没有异常指令，路子对了！但是为什么会卡死呢，我开始debug。。。
后来我想到，我这里的访问镜像内存修改了，我对应镜像里面的内存布局是不是也要修改一下？
修改过了之后，还是显示指令异常，放在qemu里可以正常运行。。。难道是因为opensbi？
今天继续debug,太痛苦了。。。
之前rCore 是将device段里的内存映射到了内核，主要是因为直接读写磁盘速度非常慢，
但是我现在是将镜像放在了内核中，是不是可以直接用?
尝试了很多方法。但是还是没用处，感觉卡在这了。。。
我翻了翻我之前的opensbi 发现一个致命的错误 我的页表初始化好像一直没开。。。。
那我后面怎么正确运行的？？？？？ 跳到之前的版本加上之后，发现内核仍可以重映射。。。
真是太幸运了，这个bug留到之后复现吧
我打算将rCore_tutorial 第二版复现一下 看看第二版如何加载放在内核中的elf镜像
搞了一天 几乎没有成果。。。
感觉能用的方法已经用的差不多了，只能还原第二版的处理了
又出来了奇怪的情况，为什么我每运行一次线程id就加一了 ,初始值是0 ,很奇怪，现在感觉跟缓存可能确实有关系
听了下学长的建议，刷了下ifence,好像确实可以!
具体的命令行是
unsafe{
llvm_asm!("fence.i" :::: "volatile");
};
应该是因为之前的cache存在一些其他的指令，所以刷新了之后就可以正常执行了
在这两天痛苦的debug过程中，我学到了很多东西，对整个os的结构加深了理解，虽然过程很辛苦，但是最后跑出来确实非常高兴！今天吃顿好的d=====(￣▽￣*)b
今天开始进行flash驱动的改写，争取可以将rust flash驱动跑在裸机上
今天参加了讨论，决定将flash放在m态，通过系统调用来实现文件系统的读写
跟洛佳讨论了之后，rustsbi中关于spi这一部分不知道什么时候能完整支持，那我先搞C
- 将sdk中的flash驱动放到opensbi中
- 在opensbi中支持读写sdk
- 等待rustSBI spi部分的实现
今天身体有点不适，没怎么看。。
fork了一下洛佳同学的rustSBI,先尝试将已经支持的lab6跑起来，再进行flash的尝试，先试试看吧。
上来就来了两个报错，后来发现居然是用的justfile,我只听过makefile.. 好在是用cargo安装的，步骤倒是很简单
现在可以跑起来了，但是很奇怪的是，到线程那里就卡死了，初始化时表现为完全正确，但是当执行时却没动静了，有点奇怪哈
llvm_asm!("sfence.vma" :::: "volatile");
这一句去掉之后就可以跑内核线程了 这跟之前的坑重合了，应该要在rustSBI进行修改
修改过之后内核态线程可以跑了，但是用户态却奇妙的出现了一个未对齐错误
猜测是因为这一句
llvm_asm!("csrw satp, $0" :: "r"(new_satp) :: "volatile");
但是这一句为什么会报错呢? 神奇
现在觉得可能是因为sbi里面没有开启sv39,但是为什么页表可以正常的用呢？
有一种可能的原因，是因为k210在处理时，将高32位舍弃了，正好将我们的虚拟地址那一块给去掉了，我现在在rustSBI中将它加上，看看是不是因为它
今日进展较慢，主要是未能找到bug的准确位置
今日继续努力将rCore在rustSBI上跑起来，我尝试将rCore的版本切换为lab3
看看大页能不能开起来，在 sfence.vma这条指令上，出现了诡异的对齐异常
现在好了，大页都开不起来了，(；′⌒)
经过艰难的debug 发现是因为RustSBI中有一个内嵌函数出了问题，导致sfence.vma没有得到处理。
最后经过SBI的修改 现在已经可以在rustSBI上跑起来 lab1-6了！
现在我先尝试用sd卡的例程 看是否例程可以正常的使用
尝试了一下，可以正常的读取，接下来就应该想办法搞到rustSBI里面去了
现在我还有个问题，我是应该先将用户镜像放在SD卡中，然后再读取吗？我想应该是这样
开始测试sd 作为系统调用 测试简单的接口，获取sd卡的信息，突然有了个奇怪的bug
Option::unwrap() on a None value
意思是没有读到东西?后来发现总线在一个程序中只能定义一次，我们在之前的初始化已经定义过了，现在没法进行定义，只能直接unsafe了
这sd卡一碰到gpio就卡死，但是它还用到了很多gpio 要不先搞flash? 搞flash的难题就是没有例程，写一个就完事了
经过对比发现，sd的一些函数跟flash的一些函数吻合度很高，比如基础的读与写，可以利用这个较快的完成flash.rs的基础函数书写，但是总体而言框架差别还是很大，希望今天可以完成基础部分改写
首先需要对spi进行改写，我写到一半，flash卡死了，准确说是还没读到，学长告诉我SD卡已经可以放在S态读写了，我去，一天白给了，┭┮﹏┭┮
现在尝试将镜像烧写进SD卡，看看行不行吧！
经过尝试，现在可以将镜像烧写进SD卡，就是有点慢，现在尝试在rCore中进行镜像的读取，说实话我一直不懂大页的映射是怎么回事，只能等有时间了问下学长了
抽象块设备这里也有点问题，有神奇的bug。。。
将SD卡抽象为块设备，底层方法基本都已经实现了，只需要包装为block对象即可使用，但是好像涉及到了生命周期?知识盲区啊
后来发现是我对trait跟泛型的理解不够到位，更改了之后，查看文件系统的库，经过一顿瞎改，终于完成了，现在可以在SD卡上运行用户程序了！
接下来我们应该在此基础上支持更多的用户程序，但是我们好像并没有那么多的系统调用
今天写的两个用户程序都被卡着了，看来我对系统调用的理解还是不够深入，明天好好研究一下
今天继续搞系统调用，经过一些调试，发现用户线程莫名其妙的被移除了？
查看了一下sepc,定位到反汇编中，有一句
lwu a0 0(a0)
意思是加载高32位到a0中，是因为这样虚拟地址->变为了物理地址？
后来我觉得应该不是这个问题，在opensbi中，我们增加了映射
0x0->0x0 0xffffffff0->0x0
0x40000000->0x40000000 0xffffffff400000000->0x40000000
后来发现我搞混了一个概念 Framed 跟 Linear完全不同 我们将设备映射过去只需要Linear offset为0 并不需要分配空间，修改过了之后，可以跑起来了 心累
但是rCore中将context放在了内核栈顶，而且只有在中断时才能恢复，所以线程间的切换似乎不太能实现，于是我将之前的切换改了一下
现在可以正常切换回来了 但是又有了奇妙的bug 切换回来之后 输8个字符就崩。。。 可能是我切换的方法不对?
更改了一下切换线程上下文的方法，现在可以正常的运行sys_exec了，接下来我想做的是虚拟存储，现在做的应该是在sd中定义一块专用来虚存的区域
首先用dd命令打包了一块100M大小的swap,真是刺激，现在我需要看一下rCore的页面置换算法是如何实现的
遇到一些小问题，例如线程会爆栈，最后比较粗暴的将初始栈的大小扩大，这里涂轶翔大佬的解释让我理解的更加深入了
这是大佬原话： 创建一个线程的时候，分配了一段栈空间。此时这段空间中的每个页面都会被添加到页表之中，但是并不是所有页面都对应了一段真实的物理帧。之后如果访问了一个栈空间的地址，能在页表中找到，但是没有对应的物理帧，这是发生了缺页异常，由操作系统来处理置换页面，把需要的页面加载到物理内存中并且更新页表。如果访问了超出栈空间的地址，这是内存非法访问，操作系统会检测到并且终止程序（就像写c程序出现segmentation fault）
还有王润基学长的指导，太感谢学长了
本来我以为没bug了，但是在我调用户程序的期间，新的bug出现了
`panic: 'called `Result::unwrap()` on an `Err` value: "panic: 'index out of bounds: the len is 689 but the index is 1024'`
这又是什么情况。。。怎么会有数组越界 经过调试 发现在一个线程时不会产生这个问题，当线程增多时就会产生这个问题 并且好像只会在用户线程中出现这个问题 很奇怪 猜测是因为镜像未对齐？ 后来发现是给用户线程分配的页有点多。。。
采用了虚拟存储虽然可以利用较多的资源，但是也带来一个坏处，就是慢。。。太慢了
现在总是会在ROOT_INODE那里卡死 why 明天再研究把。。。
今天继续调试 争取让系统调用正常工作
ROOT_INODE是Arc的，我们现在把调用ROOT_INODE放在了虚存中，结果ROOT_INODE是控制虚存的，。。。这样就死锁了吧
我想到一个折中的方法，在内核中放一个文件描述符表，其实是一个结构体，在刚开始时，我们获取它的名称以及对应的文件描述符，在删除或者修改时对它进行更新
跑了老远去买了个SD卡，结果换了SD卡之后居然有了新的异常。。。
我发现只要在用户进程中加上一句输出 就不会卡死 反而就是卡死。。。
接下来开始搞busybox
Elf文件段中的文件头 mem_size跟实际读出来的长度居然不匹配。。
Busybox的难度超过我的想象
今天有点累 就先休息一天
今天开始搞一个terminal的游戏 贪食蛇
从github上一个小项目改起来，另外发现了一个bug 只要我在用户态使用hashset就会出现elf 长度与数据不符合的bug 不知道是为什么 只能以后再研究了
终于实现了贪食蛇!
为了让k210能够正常读到字符，而且贪食蛇能动 我将阻塞读取字符改成了一次读取很多次，这样虽然很慢，但是也能达到一些效果