Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
rcore-os
RCore Tutorial Book V3
提交
d95b158f
R
RCore Tutorial Book V3
项目概览
rcore-os
/
RCore Tutorial Book V3
9 个月 前同步成功
通知
3
Star
938
Fork
153
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
R
RCore Tutorial Book V3
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
前往新版Gitcode,体验更适合开发者的 AI 搜索 >>
提交
d95b158f
编写于
4月 02, 2021
作者:
chyyuu1972
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
update ch2/sec023
上级
78eed54b
变更
3
隐藏空白更改
内联
并排
Showing
3 changed file
with
21 addition
and
1 deletion
+21
-1
source/chapter2/0intro.rst
source/chapter2/0intro.rst
+13
-1
source/chapter2/2application.rst
source/chapter2/2application.rst
+5
-0
source/chapter2/3batch-system.rst
source/chapter2/3batch-system.rst
+3
-0
未找到文件。
source/chapter2/0intro.rst
浏览文件 @
d95b158f
...
...
@@ -163,5 +163,17 @@
本章代码导读
-----------------------------------------------------
相比于上一章的操作系统,本章操作系统有两个最大的不同之处,一个是支持应用程序在用户态运行,且能完成应用程序发出的系统调用;另一个是能够一个接一个地自动运行不同的应用程序。所以,我们需要对操作系统和应用程序进行修改,也需要对应用程序的编译生成过程进行修改。
<To Be Continued>
首先改进应用程序,让它能够在用户态执行,并能发出系统调用。这其实就是上一章中 :ref:`构建用户态执行环境 <term-print-userminienv>` 小节介绍内容的进一步改进。具体而言,编写多个应用小程序,修改编译应用所需的 ``linker.ld`` 文件来 :ref:`调整程序的内存布局 <term-app-mem-layout>` ,让操作系统能够把应用加载到指定内存地址后顺利启动并运行应用程序。
应用程序运行中,操作系统要支持应用程序的输出功能,并还能支持应用程序退出。这需要完成 ``sys_write`` 和 ``sys_exit`` 系统调用访问请求的实现。 具体实现涉及到内联汇编的编写,以及应用与操作系统内核之间系统调用的参数传递的约定。为了让应用在还没实现操作系统之前就能进行运行测试,我们采用了Linux on RISC-V64 的系统调用参数约定。具体实现可参看 :ref:`系统调用 <term-call-syscall>` 小节中的内容。 这样写完应用小例子后,就可以通过 ``qemu-riscv64`` 模拟器进行测试了。
写完应用程序后,还需实现支持多个应用程序轮流启动运行的操作系统。这里首先能把本来相对松散的应用程序执行代码和操作系统执行代码连接在一起,便于 ``qemu-system=riscv64`` 模拟器一次性地加载二者到内存中,并让操作系统能够找到应用程序的位置。为把二者连在一起,需要对生成的应用程序进行改造,首先是把应用程序执行文件从ELF执行文件格式变成Binary格式(通过 ``rust-objcopy`` 可以轻松完成);然后这些Binary格式的文件通过编译器辅助脚本 ``os/build.rs`` 转变变成 ``os/src/link_app.S`` 这个汇编文件的一部分,并生成各个Binary应用的辅助信息,便于操作系统能够找到应用的位置。编译器会把把操作系统的源码和 ``os/src/link_app.S`` 合在一起,编译出操作系统+Binary应用的ELF执行文件,并进一步转变成Binary格式。
操作系统本身需要完成对Binary应用的位置查找,找到后(通过 ``os/src/link_app.S`` 中的变量和标号信息完成),会把Binary应用拷贝到 ``user/src/linker.ld`` 指定的物理内存位置(OS的加载应用功能)。在一个应执行完毕后,还能加载另外一个应用,这主要是通过 ``AppManagerInner`` 数据结构和对应的函数 ``load_app`` 和 ``run_next_app`` 等来完成对应用的一系列管理功能。
这主要在 :ref:`实现批处理操作系统 <term-batchos>` 小节中讲解。
为了让Binary应用能够启动和运行,操作系统还需给Binary应用分配好执行环境所需一系列的资源。这主要包括设置好用户栈和内核栈(在应用在用户态和内核在内核态需要有各自的栈),实现Trap 上下文的保存与恢复(让应用能够在发出系统调用到内核态后,还能回到用户态继续执行),完成Trap 分发与处理等工作。由于涉及用户态与内核态之间的特权级切换细节的汇编代码,与硬件细节联系紧密,所以 :ref:`这部分内容 <term-trap-handle>` 是本章中理解比较困难的地方。如果要了解清楚,需要对涉及到的CSR寄存器的功能有清楚的认识。这就需要看看 :ref:`RISC-V手册 <http://crva.ict.ac.cn/documents/RISC-V-Reader-Chinese-v2p1.pdf>` 的第十章或更加详细的RISC-V的特权级规范文档了。有了上面的实现后,就剩下最后一步,实现 **执行应用程序** 的操作系统功能,其主要实现在 ``run_next_app`` 函数中 。
source/chapter2/2application.rst
浏览文件 @
d95b158f
...
...
@@ -86,6 +86,9 @@
#![feature(linkage)]
.. _term-app-mem-layout:
内存布局
^^^^^^^^^^^^^^^^^^^^^^
...
...
@@ -98,6 +101,8 @@
其余的部分和第一章基本相同。
.. _term-call-syscall:
系统调用
^^^^^^^^^^^^^^^^^^^^^^
...
...
source/chapter2/3batch-system.rst
浏览文件 @
d95b158f
.. _term-batchos:
实现批处理操作系统
==============================
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录