- 递交代码的时候commit的内容要详细，直接push到主分支
git push origin或git push origin master即可。 - 代码最好加上详细的注释，说明函数的功能，一些需要特别关注的地方，用到的知识点。
- 每次开始写代码前先pull一遍
| 命名范式 | 例子 |
|---|---|
| usage_mode | sti_handler_m |
| funtionname_retaddr | _start_retaddr |
| 异常处理函数命名exceptionname_handler_mode | sti_handler_m |
随便写了几个，不遵守也不要紧。 现在调试的时候用符号设置断点，会设在虚拟地址上。如果在物理寻址模式下是无法断住的，用绝对地址才行。 如果要调试的话，可以加个-DDEBUGTEST选项，然后可以输出帮助调试的信息，最后上交的时候删掉这个-DDEBUGTEST。
大家在看别人写的代码的时候，带着批判的眼光。大家都是自己人，别客气，直接无情的指出你觉得程序可能存在的问题。 上传代码流程：
- git status查看修改情况。
- git add 需要的代码，一般
git add . - git commit -m "尽可能详细的注释，中英文均可"
- git push origin master
写代码建议：
- 先git pull origin，合并前人的工作
- 一边写，写了一会感觉要备份一下就可以git add了
- 感觉完成一个阶段的任务了就git commit 一下
- 结束工作了就push一下
- 在群里说一下
其他(具体使用GOOGLE)：
- git checkout是用来反悔的
- git log+git reset HEAD可以查看以前的代码。
文件统一用UTF-8编码
注释：
每一个函数体前要有注释说明
/* input：函数的输入 * output：函数的输出 * usage: 函数是干什么的 * other: 比如哪里还可以改进，什么需要注意的 */
C语言缩进：
统一用4个空格
所有的花括号独立一行{
}
头文件规范： 对外提供的函数接口，绝对不能出现static 宏 typedef extern 别的变量，增加程序的耦合度，如果没有必要的话就不用
命名规范： 对外提供的函数接口命名： _下划线命名
变量命名：
Makefile规范： ？？
.gitignore 忽略文件 git分支管理
我们有什么内容是妥协的操作，比如第一个进程的创建。，
- shell
- exit,wait,exec
- file system，从而更好的实现page fault的处理
- 第一个进程
- loader
- 添加更多的syscall，之前的syscall有了文件系统也要做修改
- user部分的物理地址管理，真的使用buddy吗 kmalloc, malloc?
- 解决一下现在的好多warning
- RISCV深入了解，不只是指令 PS：回顾之前的lab，把上下文关系搞清楚，给之前的代码添加必要的注释，删除不必要的注释，把之前的代码整个重构一下。
板子的写，debug 怎么更好的管理大的工程呢？ IDE？ 怎么样系统的测试呢？ SRTP 做什么，怎么准备，有什么指导建议 重构
RISCV 操作系统和Linux git Makefile 工程管理