diff --git a/_config.butterfly.yml b/_config.butterfly.yml index ea12ff7..7627210 100644 --- a/_config.butterfly.yml +++ b/_config.butterfly.yml @@ -50,7 +50,7 @@ cover: default_cover: /img/cover.jpg index_post_content: - method: 3 + method: 2 length: 500 toc: diff --git a/source/_posts/blog-mig.md b/source/_posts/blog-mig.md new file mode 100644 index 0000000..3c529fa --- /dev/null +++ b/source/_posts/blog-mig.md @@ -0,0 +1,36 @@ +--- +title: 短文 - 博客迁移小记 +date: 2024-10-13 20:35:27 +tags: + - 短文 + - 博客 + - 自言自语 +categories: + - 技术 +--- + +最开始想的迁移方案是使用 `skip-render` 标记 html，但始终觉得不够优雅，因为导航栏、个人信息、头图之类的内容时常都会变，如果 skip-render 那永远都会是当时那个版本的页面，甚至可能超链接都是失效的，除了能显示原本的博文之外其实体验应该是相当差的——横竖感觉就是很突兀嘛！ + +直到今天突然意识到，hexo 渲染 markdown 为 html 文本肯定会分为三个大部分： + +1. 正文前部的各种元素，例如头图、导航栏、侧边栏等 +2. 正文的元素 +3. 正文后部的各种元素，例如版权、脚注等 + +一拍大脑， markdown 天生兼容 html 啊！！！ + +理论上对于 html 元素 hexo 应该不会过多插手渲染，那我不是理论上可以直接找到之前渲染好的 html 文件中的正文部分直接复制到 markdown 里面然后 `hexo generate` 就完成了？！ + +立马就开始动手实践，发现真的可以！ + +不过随着 butterfly 版本的迁移，页内标签外挂 `tag` 的渲染结果从 `div-ul-li-button` 变成了 `div-button` 的层级，原本在 `li` 上的类名现在转移到了 `button` 上，遂赶紧尝试使用正则批量替换。这里用了 `
  • ([\n\s]*)]*)>([^<]*)([\n\s]*)
    • ` 这个表达式在 VSCode 里搜索匹配，然后替换为 `$4` + +很快啊！刷的一下就全部都修改好了！！！ + +![replace](/img/blog-mig/replace.png) + +然后再把原先的图片复制到现在的 `img` 目录下，批量改一手路径，Done！ + +谁能想到这个卡了我两年的问题，竟然能 15 分钟就搞定了！！！ + +过于激动，遂特写此文记录一下，真是拍大腿啊！！！ diff --git a/source/_posts/os-journal-vol-1.md b/source/_posts/os-journal-vol-1.md new file mode 100644 index 0000000..1749976 --- /dev/null +++ b/source/_posts/os-journal-vol-1.md @@ -0,0 +1,342 @@ +--- +title: 操统实验日志 第一章 序章 +date: 2022-07-15 08:36:46 +description: "简述: 在一切开始之前，请允许我先简要地介绍一下关于这个实验的一切。这一系列日志将是我对大二下学期操作系统实验课程中实验的一个整体回顾与记录。当然，在我写下这些的时候，我还完全不知道这份日志可以做到怎样的完成度，但我仍希望在我写下这些文字的暑假里能够以一系列详实、可复现的日志作为我对过去这一个学期里的这样一门有趣的课程的一个交代。我希望，通过这一系列日志，可以记录我完成一个简单操作系统的全部过程、记录在完成操作系统实验中可能遇到的难题和它们的解决方案，并作为一份简易操作系统的简易教程，帮助我自己或是别人复现这个实验。那么，准备好了吗？我们开始吧！" +tags: + - 操作系统 + - 大学 +categories: + - 技术 +--- + +

    简述

    +

    在一切开始之前，请允许我先简要地介绍一下关于这个实验的一切

    +
    +

    它是关于什么的

    +

    这一系列日志将是我对大二下学期操作系统实验课程中实验的一个整体回顾与记录。

    +

    当然，在我写下这些的时候，我还完全不知道这份日志可以做到怎样的完成度，但我仍希望在我写下这些文字的暑假里能够以一系列详实、可复现的日志作为我对过去这一个学期里的这样一门有趣的课程的一个交代。

    +

    它有什么用

    +

    我希望，通过这一系列日志，可以

    + +

    那么，准备好了吗？
    +我们开始吧！

    +
    +

    环境搭建

    +

    在介绍具体的安装方法前，先在此列出所有需要的环境，方便快速对照安装

    +

    必须的

    +

    由于实验的需要，以下环境是必须准备的

    +
    + +

    建议的

    +

    为了提升在实验过程中的编写、调试等体验，以下环境是可选的，并且在我的实现中安装的

    +
    +

    在Windows下

    + +

    在Linux下

    + +

    Ubuntu安装指南

    +

    Ubuntu版本以进行实验时的20.04LTS版本为例，其他版本的安装方式基本相同

    +
    +

    前往Ubuntu官网处下载对应版本的镜像文件

    +

    镜像下载页

    +

    下载页面会随时间改变，如果需要下载旧版本Ubuntu，可以进入alternative downloads页面下载

    +
    +

    下载得到一个文件名如ubuntu-20.04.4-desktop-amd64.iso的镜像文件

    +

    有了镜像文件以后，就可以进入下一步，在虚拟机中使用该镜像安装系统了

    +
    +

    由于我在实验中使用的是VMWare Workstation，此处以VMWare Workstation Pro 16为例进行介绍，其他虚拟机可以使用搜索引擎查询对应Linux配置方式

    +
    +

    在VMWare Workstation中安装Ubuntu的步骤如下：

    +
      +
    1. 创建新的虚拟机
      2. +
    2. 配置选择自定义（高级）
      3. +
    3. 硬件兼容性选择Workstation 16.2.x
      4. +
    4. 选择稍后安装操作系统
      5. +
    5. 安装的系统选择Linux及Ubuntu 64位
      6. +
    6. 设置名称位置
      7. +
    7. 根据CPU设置处理器内核数
      8. +
    8. 内存大小设置为4~8GiB
      9. +
    9. 网络类型设置为NAT
      10. +
    10. I/O控制器类型选择为LSI Logic
      11. +
    11. 虚拟磁盘类型选择SCSI
      12. +
    12. 磁盘选择创建新虚拟磁盘
      13. +
    13. 自由设置其他内容
      14. +
    +

    硬件配置如下

    +

    图 4

    +

    为了从上一步下载的镜像文件中安装系统，需要编辑虚拟机设置，在CD/DVD的连接栏选择使用ISO映像文件并设置为上一步中下载的镜像文件，同时勾选启动时连接

    +

    如果设备中没有找到CD/DVD，需要通过下方添加添加一个CD/DVD驱动器

    +
    +

    在启动虚拟机之前，由于在某些情况下虚拟机的显示分辨率会太低导致显示不出安装界面的下一步按钮，因此在启动之前可以在虚拟机设置中调整显示器分辨率。

    +

    这里将显示器设备中的监视器一栏设置为指定监视器设置并设置最大分辨率为当前显示器的分辨率

    +

    如果这一步没有产生效果，并且在安装时确实遇到了无法点击按钮的情况，可以在第一步选择Try Ubuntu进入桌面

    +

    之后右键在Display Settings中设置分辨率和缩放

    +

    如果没有合适的缩放，可以开启Fractional Scaling进行小数位缩放，可以多出125%、150%和175%的缩放比设置

    +
    +

    设置好后启动虚拟机，进入.iso文件中的系统，启动后会自动进入Ubuntu安装程序

    +

    如果这一步无法启动，检查CD/DVD是否设置为启动时连接

    +
    +

    安装步骤如下：

    +
      +
    1. 安装程序中选择Install Ubuntu进入安装
      2. +
    2. 检查键盘布局是否正确，具体测试方式为在输入栏中测试键盘各个键输入是否符合预期
      3. +
    3. 选择Minimal installation进行最小安装，同时可以取消勾选Download updates while installing Ubuntu，避免因为遇到无法访问的情况卡住安装，更新可以在后续换源后进行，这里可以不着急
      4. +
    4. 简便起见，在Installation type步骤可以直接选择Erase disk and install Ubuntu，如果有自己的分区喜好，可以选择Something else，具体分区方式网上有完备介绍，可以跟随教程设置，完成后选择Install Now
      5. +
    5. 时区选择Shanghai
      6. +
    6. 设置用户名密码
      7. +
    7. 点选Continue执行安装即可
      8. +
    +

    在安装完成之后，系统会提示是否重启系统，由于需要关闭CD/DVD驱动器以免再次进入安装系统，在这一步不进行重启系统，关闭该通知进入系统桌面，右上角菜单选择关机，关机过程中会有一个提示移出安装媒介并按回车键，直接按回车关机即可

    +

    关机后进入编辑虚拟机设置页，移出CD/DVD设备或是取消勾选该设备的启动时连接

    +

    完成后启动虚拟机进入安装好的系统，开机后使用安装时设置的用户密码登录，初次启动会有一些提示框，基本一直下一步即可进入桌面

    +

    进入系统以后同样会遇到分辨率问题，可以参照上文调整分辨率和缩放

    +
    +

    一切准备好之后，就可以进行下一步的换源操作了

    +

    此处以清华源为例进行配置，同样也可以选择企业提供的镜像源，如阿里源，在一定程度上企业源会比大学镜像源更加可靠，可以酌情选择

    +
    +

    换源实质上就是更改系统所使用的软件源的配置文件，因此要做的事就只有两件：

    +
      +
    • 去使用的源的网站获取当前版本的配置文件
      • +
    • 修改系统中原本的配置文件
      • +
    +

    清华源中给出的Ubuntu 20.04 LTS版本的配置文件如下，复制该配置文件内容

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    # 默认注释了源码镜像以提高 apt update 速度，如有需要可自行取消注释
    deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal main restricted universe multiverse
    # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal main restricted universe multiverse
    deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-updates main restricted universe multiverse
    # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-updates main restricted universe multiverse
    deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-backports main restricted universe multiverse
    # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-backports main restricted universe multiverse
    deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-security main restricted universe multiverse
    # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-security main restricted universe multiverse

    # 预发布软件源，不建议启用
    # deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-proposed main restricted universe multiverse
    # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ focal-proposed main restricted universe multiverse
    +

    对于不同版本的Ubuntu，配置文件会有所不同，体现在链接后面的focal字样，该字段是Ubuntu的版本号，例如Ubuntu 18.04的版本号就是仿生鱼bionic而Ubuntu 22.04LTS版本号为jammy

    +

    如果选择了错误的配置文件，会使得后续apt update环节出现奇怪的错误，因此一定要选择版本对应的配置文件

    +
    +

    在终端中输入

    +
    1
    sudo vim /etc/apt/sources.list
    +

    如果还没有安装vim，可以

    +
      +
    • 改成使用vi而不是vim，在换源后再安装vim
      • +
    • 执行sudo apt-get update && sudo apt-get install vim安装vim继续
      • +
    +
    +

    首先注释掉原先的内容，然后在文件尾追加上文中复制的配置文件，之后保存退出

    +

    在vim中使用I进入编辑模式，使用ESC退出编辑模式

    +

    在非编辑模式下输入:wq保存并退出，输入:q退出，输入:q!放弃更改退出

    +
    +

    在vim中可以使用如下方式批量添加注释

    +
      +
    1. Ctrl+V进入列选择模式
      2. +
    2. J / K / ↓ / ↑ 移动光标选中行
      3. +
    3. Shift+I（这一步会让光标移到选中列的第一行第一个字符之前，但实际上光标在所有选中行的第一个字符之前）
      4. +
    4. Shift+3（输入注释符#）
      5. +
    5. ESC退出
      6. +
    +
    +

    保存了新的配置文件以后，执行如下命令执行更新

    +
    1
    sudo apt-get update
    +

    执行了更新之后就完成了换源的全部步骤，可以进入下一步安装其他软件环境了！

    +

    安装C/C++环境

    +
    +

    终端执行以下命令

    +
    1
    2
    sudo apt install binutils
    sudo apt install gcc
    +

    或者使用一行命令

    +
    1
    sudo apt install binutils && sudo apt install gcc
    +

    检查是否安装成功

    +
    1
    gcc -v
    +

    如果输出gcc的版本号则表明安装成功

    +

    安装NASM

    +
    +

    首先检查已经安装的nasm版本

    +
    1
    nasm -v
    +

    如果已经是2.15^版本则可以跳过本节，如果不是的话则需要安装2.15^版本的nasm

    +

    首先根据网上教程的指引，下载压缩包

    +
    1
    2
    $ wget https://www.nasm.us/pub/nasm/releasebuilds/2.15.05/nasm-2.15.05.tar.xz
    Download time (Average speed) - `nasm-2.15.05.tar.xz` saved [995732/995732]
    +

    然后进行解压和配置文件生成

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    $ tar -xvf nasm-2.15.05.tar.xz
    nasm-2.15.05/
    nasm-2.15.05/AUTHORS
    ...
    nasm-2.15.05/doc/nasmlogw.png

    $ cd nasm-2.15.05/

    $ ./configure
    checking for prefix by checking for nasm... no
    ...
    configure: creating ./config.status
    config.status: creating Makefile
    config.status: creating doc/Makefile
    config.status: creating config/config.h
    +

    上面的bash代码不要直接复制，其包含了输出的显示

    +

    只有 $ 后的内容才需要输入，其他的内容为预期的输出显示

    +
    +

    最后进行make安装

    +
    1
    2
    make
    sudo make install
    +

    安装LLVM

    +
    +

    如果打算使用LLVM作为编译器，则可以参照官网安装指南进行安装，下面给出脚本安装方式

    +
    1
    sudo bash -c "$(wget -O - https://apt.llvm.org/llvm.sh)"
    +

    安装后的clang可能不叫作clang，因此直接执行clang -v可能会报错未安装

    +

    输入clang后按TAB两次可以看到安装了的clang版本，例如clang-14和clang++-14，这样输入clang-14 -v就能够显示版本了

    +

    之后在编写makefile的时候也要注意不要将编译器写为单独的clang，而是带后缀的安装了的版本

    +
    +

    安装其他工具

    +
    +

    终端执行以下命令

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    sudo apt install git
    sudo apt install qemu
    sudo apt install cmake
    sudo apt install libncurses5-dev
    sudo apt install bison
    sudo apt install flex
    sudo apt install libssl-dev
    sudo apt install libc6-dev-i386
    sudo apt install gcc-multilib 
    sudo apt install g++-multilib
    +

    或是输入一行指令

    +
    1
    sudo apt install git && sudo apt install qemu && sudo apt install cmake && sudo apt install libncurses5-dev && sudo apt install bison && sudo apt install flex && sudo apt install libssl-dev && sudo apt install libc6-dev-i386 && sudo apt install gcc-multilib && sudo apt install g++-multilib

    通过设置Ubuntu环境下的SSH，可以让Windows能够通过SSH连接到Ubuntu环境的shell，从而可以在Windows环境下完成大部分操作

    +

    除此之外，通过VSCode中的Remote插件，可以在Windows环境下编写Ubuntu中的文件

    +

    如果你希望在Ubuntu中完成所有代码的编写，则这一步不是必须的

    +
    +

    通过如下命令安装ssh

    +
    1
    sudo apt-get install ssh
    +

    之后配置密钥登录所必须的文件目录和文件并设置权限

    +
    1
    2
    3
    4
    mkdir ~/.ssh && cd ~/.ssh
    touch authorized_keys
    chmod 600 ~/.ssh/authorized_keys
    chmod 700 ~/.ssh
    +

    通过修改sshd配置文件关闭密码登录并打开密钥登录

    +

    打开sshd_config文件

    +
    1
    sudo vim /etc/ssh/sshd_config
    +

    之后在# Authentication:下修改如下键值，同时如果有注释则关闭注释

    +
    1
    2
    PubkeyAuthentication yes
    PasswordAuthentication no
    +

    保存退出后重启sshd服务

    +
    1
    service sshd restart
    +

    之后，需要在VMWare Workstation里转发22端口到虚拟机

    +

    为了完成这个任务，需要先获取虚拟机的ip地址

    +
    1
    2
    3
    4
    $ ip a
    ...
    inet 192.168.XXX.XXX/24 brd 192.168.XXX.255 scope global dynamic noprefixroute ens33
    ...
    +

    可以看到输出中给出的ipv4地址，这里假设为192.168.85.130，记住该地址

    +

    进入VMWare Workstation中的 编辑-虚拟网络编辑器-更改设置-VMnet8 NAT模式-NAT设置，添加端口转发规则

    + + + + + + + + + + + + + + + + + + + +
    主机端口类型虚拟机IP地址虚拟机端口描述
    22TCP192.168.85.13022SSH
    +

    保存并应用设置就完成了端口转发的添加

    +

    最后，为了能够让Windows能够顺利连接上虚拟机，需要在Windows环境下生成密钥并且拷贝公钥到上文中创建的authorized_keys文件中

    +

    下述操作将在Windows环境中进行

    +
    +

    首先，需要在Windows环境下安装OpenSSH，参照Microsoft官方文档给出的指南，可以使用Powershell安装OpenSSH

    +

    以管理员身份运行Powershell并且检查OpenSSH的安装情况

    +
    1
    Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'
    +

    如果两者均没有安装，则会返回如下输出

    +
    1
    2
    3
    4
    5
    Name  : OpenSSH.Client~~~~0.0.1.0
    State : NotPresent

    Name  : OpenSSH.Server~~~~0.0.1.0
    State : NotPresent
    +

    之后，根据需要安装对应未安装的组件

    +
    1
    2
    3
    4
    5
    # Install the OpenSSH Client
    Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

    # Install the OpenSSH Server
    Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
    +

    这两者都应该返回如下输出

    +
    1
    2
    3
    Path          :
    Online        : True
    RestartNeeded : False
    +

    之后，使用终端生成密钥

    +
    1
    2
    3
    ssh-keygen -t rsa
    # Or
    ssh-keygen -t ed25519
    +

    根据提示设置对应的文件位置（默认为%USERPROFILE%\.ssh\id_rsa）以及密码

    +

    然后使用cat命令显示公钥内容，假定公钥文件为C:\Users\Linloir\.ssh\id_ed25519.pub

    +
    1
    cat C:\Users\Linloir\.ssh\id_ed25519.pub
    +

    会返回一个类似如下的输出

    +
    1
    ssh-ed25519 AAAAC3N******************TzC6 linloir@******
    +

    拷贝该输出，并回到Linux操作

    +

    如果希望在Windows和Linux虚拟机间复制内容，可以在VMWare中安装VMWare Tools或Open VM Tools

    +
    +

    如果VMWare Tools安装选项为灰色，可以参照网上的博客进行如下操作

    +
      +
    1. 关闭虚拟机
      2. +
    2. 打开虚拟机设置
      3. +
    3. 如果在前序步骤删除了CD/DVD设备，则添加回来
      4. +
    4. 取消勾选CD/DVD设备的 启动时连接，同时勾选 使用物理驱动器-自动检测
      5. +
    5. 重启虚拟机
      6. +
    +
    +

    在测试过程中，安装VMWare Workstation自带的VMWare Tools会提示建议安装Open VM Tools

    +

    可以结束安装并参照官方文档或是Github页面中的指南使用sudo apt-get install open-vm-tools-desktop安装

    +
    +

    在Linux终端中使用vim修改authorized_keys文件

    +
    1
    vim ~/.ssh/authorized_keys
    +

    进入编辑模式粘贴上文中复制的密钥内容后保存退出

    +

    最后可以在Windows环境下使用下述命令测试连接到虚拟机

    +

    在<username>中填写Linux用户名，<ip>填写前文中获得的虚拟机ip地址

    +
    +
    1
    ssh <username>@<ip>
    +

    如果连接成功，则证明完成了SSH的全部配置内容，同样，也完成了Ubuntu环境的全部配置！

    +

    接下来，可以直接进入下一节或是跟随教程完成Windows下使用工具的配置和安装

    +
    +

    Windows环境配置指南

    +

    如果希望在Linux环境下完成所有代码编写与调试，可以跳过此节

    +
    +

    为了提升代码编写体验，在本节中将会介绍如何在Windows环境下配置和使用VSCode以及其插件，从而能够在Windows环境下使用VSCode编写Linux中的代码

    +

    同样，还会介绍通过Windows终端连接Linux终端的方式，并在Windows环境下配置Linux环境中的ZSH终端以及powerlevel10k主题

    +

    前往VSCode官网下载并安装VSCode

    +

    安装完成后进入VSCode页面，在左侧栏中有一积木样图标，点击进入VSCode的插件安装页

    +

    搜索并安装以下插件，具体安装的插件可以根据自己的喜好选择，其中Remote家族为连接虚拟机所需要的插件

    +
      +
    • C/C++ (Microsoft)
      • +
    • Chinese (Simplified)(简体中文) Language Pack For Visual Studio Code (Microsoft)
      • +
    • CMake Tools (Microsoft)
      • +
    • Hex Editor (Microsoft)
      • +
    • Remote - SSH (Microsoft)
      • +
    • Remote - SSH:Editing Configuration Files (Microsoft)
      • +
    • The Netwide Assembler (NASM) (Right)
      • +
    +

    在完成了Remote家族插件的安装后，侧边栏会有一远程连接的图标，点击可以进入远程资源管理器

    +

    选择SSH Target以添加虚拟机，之后在SSH TARGETS菜单处点击添加键，在弹出窗口中输入

    +
    1
    ssh <username>@<ip>
    +

    在弹出的Select SSH configuration file to update页面中选择默认选项，也即直接按回车

    +

    之后在左侧SSH TARGETS菜单栏能够看到新添加的地址，鼠标移至其上方，点击其右侧文件夹图标在新窗口中打开

    +

    在Select the platform for the remote host窗口中选择Linux

    +

    之后输入在上文 配置SSH 中生成密钥步骤中设置的密码即完成连接

    +

    快试试在侧边栏中的文件页面中打开Ubuntu中的项目文件夹吧！

    +

    在我的实验中，在Windows中使用了Windows Terminal，在Linux中使用了ZSH+powerlevel10k的组合，你也可以根据你的喜好设置自己的终端和主题

    +
    +

    首先，在Windows Terminal中使用ssh连接到虚拟机终端

    +

    之后，根据ZSH Wiki页面的教程安装ZSH

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    # 安装
    $ sudo apt install zsh

    # 验证安装
    $ zsh --version
    zsh 5.8 # 或者是更新的版本

    # 设置为默认shell
    $ chsh -s $(which zsh)

    # 退出登录
    $ exit
    +

    然后重新使用ssh登录，初次进入会进行设置，可以根据自己的喜好进行设置或者直接选择Populate your ~/.zshrc with the configuration recommended by the system administrator and exit进行默认设置

    +

    关于各个设置项作用将会在日后更新（如果有空）

    +
    +

    之后依据Oh My Zsh官网来安装Oh-My-Zsh框架

    +
    1
    sh -c "$(wget https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh -O -)"
    +

    完成设置就代表着Zsh安装完成，可以进行后续主题安装

    +
    +

    在安装powerlevel10k主题前，需要安装其依赖的字体

    + +

    双击打开下载的字体文件进行安装，之后进入Windows Terminal → 设置 → 配置文件 → 默认值 → 外观 → 字体，选择MesloLGS NF字体

    +

    然后使用git安装该主题

    +
    1
    git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k
    +

    可以使用gitee加速下载

    +
    1
    git clone --depth=1 https://gitee.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-$HOME/.oh-my-zsh/custom}/themes/powerlevel10k
    +

    在~/.zshrc中设置ZSH_THEME="powerlevel10k/powerlevel10k并重启Zsh

    +
    1
    2
    vim ~/.zshrc
    exec zsh
    +

    之后根据设置向导设置主题即可得到一个漂亮的终端啦

    +

    目前为止，环境已经基本配置完成了
    +接下来就让我们开始愉快的操作系统实验之旅吧！

    +
    diff --git a/source/_posts/os-journal-vol-2.md b/source/_posts/os-journal-vol-2.md new file mode 100644 index 0000000..8dbd971 --- /dev/null +++ b/source/_posts/os-journal-vol-2.md @@ -0,0 +1,789 @@ +--- +title: 操统实验日志 第二章 万丈高楼平地起 +date: 2022-07-16 05:34:21 +description: 本章的将会首先介绍操作系统是如何运行起来的，并在此基础上介绍实现一个完备的操作系统实验需要实现哪些方面，以及这些部分的先后顺序和依赖关系。在本章的后半部分，将会介绍MBR和中断的相关知识，记录如何编写MBR、测试使用BIOS启动MBR引导程序并通过中断输出字符串进行测试 +tags: + - 操作系统 + - 大学 +categories: + - 技术 +--- + +

    关于本章

    +

    本章的序将会首先介绍操作系统是如何运行起来的，并在此基础上介绍实现一个完备的操作系统实验需要实现哪些方面，以及这些部分的先后顺序和依赖关系

    +

    由于这份文档我并不打算作为一份完备的教程文档来编写，因此语言方面的介绍会相对简略或是跳过，对应的详细介绍可以参考学校的同步教程

    +

    在本章的后半部分，将会介绍MBR和中断的相关知识，记录如何编写MBR、测试使用BIOS启动MBR引导程序并通过中断输出字符串进行测试

    +

    在下一章节，将会介绍如何从MBR中加载Bootloader并进行更复杂的启动准备操作

    +

    序

    +

    计算机是如何启动的

    +

    这里介绍的启动方式是x86架构下的BIOS启动过程，UEFI启动或是在arm架构下启动则是另一种启动方式
    +由于本实验使用的是BIOS启动，因此不对UEFI启动和arm架构相关内容进行介绍，有兴趣可以使用搜索引擎进行了解

    +
    +

    经典的BIOS启动过程分为了如下五个步骤：

    +
      +
    1. +

      加电开机：
      +按下电源开关以后，电源就会开始向主板和其他设备供电，由于电压还不稳定，主板上的控制芯片组会向CPU发出并保持一个reset信号，初始化CPU。当芯片组检测到电源已经稳定供电则会撤去reset信号，之后CPU立马开始从 0xFFFF0 处执行指令。需要注意的是，这些指令并不需要我们来编写，它们位于系统的BIOS地址范围内。在 0xFFFF0 处实际存放的是一个跳转指令，它指向BIOS真正的启动代码的位置，CPU执行该指令后便进入下一步 BIOS启动 过程

      +
      2. +
    2. +

      BIOS启动：
      +在这一步中，BIOS会进行自检，也称为POST (Power-On-Self-Test)，检查系统的关键设备比如内存、显卡等是否正常工作。如果检测到这些关键设备存在致命问题，则会通过蜂鸣音来报告错误，蜂鸣音的长短即次数对应错误类型。在完成自检之后，BIOS就会进入下一步加载MBR并启动

      +
      3. +
    3. +

      加载MBR：
      +MBR，全称为主引导记录 (Master-Boot-Record) ，它存储在存储设备的首扇区512字节。MBR包含了如下的三个部分：

      +
        +
      • 启动相关的代码：
        +在MBR的前446字节中存储了启动引导程序，由于这部分空间太小，没有办法完成很复杂的启动操作，所以计算机会将主要的启动准备操作都放在下一步的bootloader中进行，而这部分引导程序的主要作用就是从磁盘中加载bootloader到内存然后跳转到bootloader的地址上运行
        • +
      • 磁盘分区记录：
        +MBR的447~510这64个字节中存储的是分区表信息，每个分区需要16字节，包括了分区的引导标志、起始磁道、起始扇区、起始柱面等信息。这部分分区表最多能够存储四个分区的信息
        • +
      • 结束标记：
        +MBR的最后两个字节是一个魔数 (Magic number)，通过 0xAA55 标记这个设备是可以启动的，也就是这512个字节的MBR是有效的
        • +
      +

      因此在BIOS启动之后，它便会根据设置好的引导顺序，按排位顺序检查引导序列中对应地存储设备是否可以启动 （也就是检查MBR的最后两个字节是否是0x55AA），如果满足要求，则复制这512字节到内存中的 0x7C00 地址处，然后跳转到该地址开始执行MBR中启动相关的代码

      +

      关于为什么MBR是被加载到0x7C00，而不是加载到0x0000，可以参考Why BIOS loads MBR into 0x7C00 in x86 ?这篇文章

      +
      +
      4. +
    4. +

      加载bootloader：
      +在CPU跳转到 0x7C00 处之后，就会开始执行MBR中的代码，这部分代码将会由我们编写。在这部分代码中，MBR会从磁盘加载bootloader的代码进入内存，进入保护模式，然后跳转到bootloader处执行

      +
      5. +
    5. +

      加载kernel：
      +进入bootloader以后，操作系统会进行相当多准备操作，例如加载文件系统、开启分页机制等，在完成这些工作之后，bootloader会从文件系统中装载系统内核进入内存，然后跳转到内核执行

      +

      当进入内核以后，操作系统就基本完成了启动的过程，内核会完成后续操作系统的初始化操作，这些将留到编写内核的时候再详述

      +
      6. +
    +

    启动过程不是绝对的，从MBR之后的启动方式可以按照自己的设计进行
    +例如，在MBR中可以加载类似grub的代码，在第一阶段加载文件系统，然后从系统路径里加载第二阶段的代码，并且在第二阶段中实现多系统引导，加载对应系统的kernel文件然后跳转运行

    +
    +

    前序知识

    +

    在这一章节中将会介绍在后续实验中将会大量使用的基础知识，包括了nasm的语法以及常用概念的解释等

    +

    这些内容大部分在用到的时候也会在文章中再次出现
    +所以如果想要尽快开始实验，不妨跳过这个章节，继续后面的内容

    +
    +

    nasm语法

    +

    IA-32 处理器
    +IA-32处理器是指从Intel 80386开始到32位的奔腾4处理器，是最为经典的处理器架构
    +其有三种基本操作模式：保护模式、实地址模式(简称实模式)、系统管理模式和虚拟8086模式
    +我们在操作系统实验过程中仅用到实模式和保护模式

    +
    +

    IA-32处理器有8个通用寄存器eax, ebx, ecx, edx, ebp, esp, esi, edi

    +

    除此之外，还有6个段寄存器cs, ss, ds, es, fs, gs

    +

    以及标志寄存器eflags和指令寄存器eip

    +

    更多的寄存器
    +后面的实验中，还会遇到更多寄存器，比如开启保护模式需要用到的cr0，存储页目录表基地址的cr3、存储产生缺页错误的地址的寄存器cr2等
    +但是目前暂时只需要使用到上面的寄存器

    +
    +

    在nasm中，除了可以直接使用上述的名字访问寄存器的全部内容，还提供了访问部分寄存器低位数据的访问方式：

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    [31:0][15:0][15:8][7:0]
    eaxaxahal
    ebxbxbhbl
    ecxcxchcl
    edxdxdhdl
    esisi––
    edidi––
    espsp––
    ebpbp––
    +

    同时，nasm还有一套约定俗成的规矩，用来指定寄存器的作用

    +

    其中，有一些规定是被 默认使用 的：

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    寄存器作用
    eax在乘法和除法指令中被自动使用
    同时也用做返回值寄存器，C或C++函数的返回值放置在eax中
    ecx在循环 (loop) 指令中被默认为计数器
    也即将循环次数存储在ecx中，loop指令只有当ecx为0时停止
    esp在对栈进行push和pop操作时，会自动从esp中取基地址
    也即push eax实际上相当于sub esp, 4，mov eax, [esp]
    esi, edi用于内存数据高速传送，本次实验中用不到
    ebp通常用于在栈上取数据时使用，一般不用于算数或是数据传输
    后续C++与asm混编后会经常遇到关于ebp的内容
    cs16位代码段寄存器
    ds16位数据段寄存器
    ss16位栈段寄存器
    +

    还有一些类似于习惯的规定，似乎不遵守它们也不会让程序出现错误：

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    寄存器作用
    eax一般用于算数运算
    比如add eax, 4，因而也叫做累加寄存器
    ebx基地址寄存器，用于在取址时提供基地址
    比如mov eax, dword [ebx + 2]为取出ebx + 2位置上32位的数据放入eax
    edx数据寄存器
    esi源变址寄存器，用于在取值时提供偏移的地址
    比如mov eax, dword [ebx + esi + 2]或是mov eax, dword [esi + 2]
    edi目的变址寄存器，用于在取值时提供偏移的地址
    比如mov dword [edi + 2], eax
    es, fs, gs16位附加段寄存器，用来存放其他的段
    +

    寻址
    +基地址寄存器和变址寄存器涉及到 寻址 相关的内容，可以前往寻址页面查看

    +
    +

    段寄存器
    +段寄存器涉及到 保护模式 相关的内容，可以前往基本概念查看

    +

    标识符是我们取的名字，用来表示变量、常量、过程、函数或代码标号

    +

    标识符满足如下要求和特性：

    +
      +
    • 至少1个字符，最多247个字符
      • +
    • 大小写不敏感
      • +
    • 第一个字符必须是字母、_或是@，后续字符可以包含数字
      • +
    • 不能与保留字相同
      • +
    +

    下面是一些有效的标识符

    +
    1
    2
    3
    4
    5
    6
    var1 
    Count 
    _main 
    MAX 
    open_file 
    @myfile
    +

    下面是一些使用标识符的示例

    +
    1
    2
    3
    4
    5
    6
    ; Function
    function_1:
      ret

    ; Data
    count dw 100

    标号是充当指令或数据位置标记的标识符，可以直接将其理解为一个地址值，指向的是其之后指令或是数据的起始地址

    +

    例如

    +
    1
    count dw 100
    +

    中count指向的就是其之后4字节长度的数据100的起始地址

    +

    如果有更长的数据，则可以这样写

    +
    1
    2
    pgdt dw 0
         dd 0x8800
    +

    在.asm文件中，可以视为地址是从第一行代码向下增长的

    +
    +

    这样写相当于声明了一个值为0x880000000000的数据

    +

    其低4字节为dw 0所声明的值，高2字节为dd 0x8800声明的值

    +

    而pgdt指向其低四字节的起始地址，也即该数据最低字节的地址

    +

    IA-32为小端序
    +在实验中使用的IA-32处理器所使用的是小端序 (little-endian)
    +这意味着数据的低位被放在低地址处而高位被放在高地址处
    +对于一个多字节的数据，其标识符指向的是它的最低字节数据地址

    +
    +

    标号也可以用于声明相当于C语言中数组的数据项

    +

    数据项之间以,分隔，标号指向第一个数据项最低字节的地址

    +
    1
    2
    array dw 1024, 2048
          dw 4096, 8192
    +

    上述代码按照1024，2048，4096，8192的顺序存放数据，同时array指向1024

    +

    标号也可以用来在过程中添加标记以方便跳转

    +
    1
    2
    3
    4
    Stage_1:
      mov eax, ebx
      ; 省略其他步骤
      jmp Stage_1 ; 跳转到 Stage_1 处执行
    +

    这里，Stage_1并不会编译成汇编代码，而是会编译为mov eax, ebx这一步的地址值，jmp Stage_1相当于跳转到mov eax, ebx这句执行

    +

    标号后面的换行和空格并不会影响标号的值
    +也就是说Stage_1: mov eax, ebx中Stage_1跟上面的代码拥有一样的标号值

    +

    如何理解寻址
    +寻址可以理解为代码获得某个数据的方式
    +例如，寄存器寻址 可以理解为代码通过寄存器获得数据

    +
    +

    nasm有六种寻址方式，分别为

    +
      +
    • +

      寄存器寻址：操作数存放在寄存器中，从寄存器中取得数据

      +
      1
      mov eax, ebx ; eax = ebx
      +
      • +
    • +

      立即数寻址：直接将立即数作为操作数

      +
      1
      mov eax, 0x20 ; eax = 0x20
      +
      • +
    • +

      直接寻址：从立即数或是标号指向的地址处取得数据

      +

      从立即数指向的地址取得数据

      +
      1
      2
      3
      4
      5
      6
      ; 从0x5C00处取得数据
      ; 
      ; 相当于C语言中
      ; uint32* ptr = (uint32*)0x5C00;
      ; eax = *ptr
      mov eax, dword [0x5C00]
      +

      也可以从标号指向的地址取得数据

      +
      1
      2
      tag dw 0x20
      mov eax, dword [tag]  ; eax = 0x20
      +
      • +
    • +

      基址寻址：将基址寄存器所储存的数值视为地址并从该地址处取得数据

      +

      基址寻址类似于数组的寻址，基址寄存器只能是寄存器bx或bp

      +
      1
      2
      3
      tag dw 0x20
      mov ebx, tag  ; ebx中存储的是tag的值，也就是0x20的地址
      mov eax, dword [ebx]  ; eax = 0x20
      +

      基址寻址也可以使用基址寄存器和立即数来构成真实的偏移地址

      +
      1
      2
      3
      4
      5
      6
      tag dw 0x20
      ; 构造一个与tag对应的地址差4的地址存入ebx
      mov ecx, tag
      sub ecx, 4
      mov ebx, ecx
      mov eax, dword [ebx + 4]  ; eax = 0x20
      +
      • +
    • +

      变址寻址：使用变址寄存器和立即数来构成真实的偏移地址，从该地址处取得数据

      +

      变址寻址与基址寻址相似，变址寄存器只能是si或di

      +
      1
      2
      mov eax, dword [esi + 4 * 4] ; eax = *(uint32*)(esi + 4 * 4)
      mov dword [edi], 0x5 ; *(uint32*)edi = 0x5
      +
      • +
    • +

      基址变址寻址：通过基址寄存器、变址寄存器、立即数来构成真实的偏移地址，从该地址处取得数据

      +
      1
      mov eax, dword [ebx + esi + 4 * 5] ; eax = *(uint32*)(ebx + esi + 4 * 5)
      +
      • +
    +

    不够用的地址？
    +在 实模式 下，IA-32处理器使用 20位 的地址线
    +不难发现在这种情况下可以访问的内存范围为220=1MB2^{20} = 1MB，范围从0x0000到0xFFFF
    +但是寄存器只有 16位，意味着使用基址、变址寻址的时候没办法访问到所有的内存地址

    +
    +

    为了解决这个问题，工程师提出了 段 的概念，使用了段地址之后，实际的地址可以表示为

    +

    Addr=(SegmentAddr<<4)+ShiftAddrAddr = (SegmentAddr << 4) + ShiftAddr +

    +

    也就是物理地址由左移4位的段地址加上偏移地址组成，这个偏移地址就由标号或是寄存器提供

    +

    此段非彼段
    +目前我们讨论的是 实模式 下的问题，此时的段是用来解决寄存器不足以访问所有的内存地址的问题
    +在后面的 保护模式 中，还将看到另一个段定义，它与本节所述的段并不是同一个概念

    +
    +

    段地址的使用一般出现在使用[]来寻址的操作中，因为在这种情况下[]内表示的是一个地址，而这个地址很可能由一个16位的寄存器或是标号提供

    +

    添加了段地址的寻址语法为

    +
    1
    mov ax, word [ds:bx]
    +

    在默认的情况下，系统会根据使用的标号和寄存器自动指定段地址，指定的段地址与使用的基址寄存器有直接关系

    +

    由于这里讨论的是实模式，所以只讨论16位寄存器

    +
    +

    对于bx、si、di，默认的段寄存器为ds

    +

    对于bp，默认的段寄存器为ss

    +

    对于基址变址寻址方式，默认的段寄存器以基址寄存器的使用为准

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    ; 下面的语句等价
    mov ax, word [tag]
    mov ax, word [ds:tag]

    ; 下面的语句等价
    mov ax, word [bx]
    mov ax, word [ds:bx]

    ; 下面的语句等价
    mov ax, word [bp + si + 4 * 4]
    mov ax, word [ss:bp + si + 4 * 4]

    下文中可能用到的标识符解释如下

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    标识符意义
    reg寄存器
    imm立即数
    immXX位立即数
    tag标号
    mem使用寻址方式取得的内存数据，例如[ebx]
    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    ; Syntax
    mov [dest], [src]

    ; Usage
    mov <reg>, <reg/imm>
    mov <reg>, <size> [<reg/imm/tag>]
    mov <size> [<reg/imm/tag>], <reg/imm>

    ; Example
    mov eax, ebx
    mov eax, 0x20
    mov eax, dword [ebx]
    mov eax, dword [0x8800]
    mov eax, dword [tag]
    mov dword [eax], ebx
    mov dword [eax], 0x20
    mov dword [0x8800], ebx
    mov dword [0x8800], 0x20
    mov dword [tag], ebx
    mov dword [tag], 0x20
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    ; Syntax
    add/sub [dest & op1], [op2]

    ; Usage
    add/sub <reg>, <reg/imm/mem>
    add/sub <mem>, <reg/imm>

    ; Example
    add eax, ebx
    sub eax, 0x20
    add eax, dword [tag]
    sub dword [tag], ebx
    add dword [tag], 0x8800

    imul完成整数乘法操作

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    ; Syntax
    imul [dest & op1], [op2]
    imul [dest], [op1], [op2]

    ; Usage
    imul <reg>, <reg/mem>
    imul <reg>, <reg/mem>, <imm>

    ; Example
    imul eax, ebx
    imul eax, dword [var]
    imul esi, edi, 25
    imul esi, dword [shift], 4
    +

    idiv完成整数除法操作

    +

    idiv只有一个操作数，此操作数为除数，而被除数则为edx:eax中的内容 (一个64位的整数)

    +

    操作的结果有两个部分

    +
      +
    • 商：存放在eax寄存器中
      • +
    • 余数：存放在edx寄存器中
      • +
    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    ; Syntax
    idiv [divisor]

    ; Usage
    idiv <reg/mem>

    ; Example
    idiv ebx
    idiv dword [var]

    shl，shr表示逻辑左移和逻辑右移，空出的位补0

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    ; Syntax
    shl/shr [target], [shift]

    ; Usage
    shl/shr <reg/mem>, <con>
    shl/shr <reg/mem>, cl ; cl为ecx低8位

    ; Example
    shl eax, 5
    shr dword [ebx], 4
    shl eax, cl
    shr dowrd [ebx], cl

    inc，dec指令分别表示自增1或自减1

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    ; Syntax
    inc/dec [target]

    ; Usage
    inc/dec <reg/mem>

    ; Example
    inc eax
    dec byte [tag]

    and, or, xor分别表示将两个操作数逻辑与、逻辑或和逻辑异或后放入到第一个操作数中

    +
    1
    2
    3
    4
    5
    6
    ; Syntax
    and/or/xor [dest & op1], [op2]

    ; Usage
    and/or/xor <reg/mem>, <reg/imm>
    and/or/xor <reg>, <mem>
    +

    not表示对操作数每一位取反，neg表示对操作数取负

    +
    1
    2
    3
    4
    5
    6
    7
    ; Syntax
    not [target]
    neg [target]

    ; Usage
    not <reg/mem>
    neg <reg/mem>

    jmp指令是无条件跳转指令，跳转到代码标号的指令处执行

    +
    1
    2
    3
    4
    5
    6
    7
    8
    ; Syntax
    jmp [addr]

    ; Usage
    jmp <tag>

    ; Example
    jmp func_1
    +

    除了无条件跳转指令外，还有条件跳转指令

    +
    1
    2
    3
    4
    5
    6
    7
    je <tag>   ; jump when equal
    jne <tag>  ; jump when not equal
    jz <tag>   ; jump when last result was zero
    jg <tag>   ; jump when greater than
    jge <tag>  ; jump when greater than or equal to
    jl <tag>   ; jump when less than
    jle <tag>  ; jump when less than or equal to
    +

    在使用条件跳转指令之前，要先进行判断，判断使用的是cmp指令

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    ; Syntax
    cmp [op1], [op2]

    ; Usage
    cmp <reg/mem>, <reg/imm>
    cmp <reg>, <mem>

    ; Example
    cmp eax, 10
    +

    一个条件跳转的示例如下，其展示了一个不适用loop指令循环10次的简单实现

    +
    1
    2
    3
    4
    5
    6
    7
    8
    xor eax, eax
    mov eax, 10
    loop_start:
      dec eax
      cmp eax, 0
      je exit
      jmp loop_start
    exit:

    push和pop为栈操作，负责将寄存器值压栈、弹栈

    本页的内容基于x86 Instruction Set Reference中关于in指令的介绍以及x86 Instruction Set Reference中关于out指令的介绍

    +
    +

    in、out为端口读写操作，它们的操作数非常严格

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    ; Syntax
    in [dest], [src]  ; Input byte from [src] port to [dest] register
    out [dest], [src] ; Output byte from [src] register to [dest] port

    ; Usage
    in al/ax/eax, <imm8/dx>   ; imm8 means a byte immediate
    out <imm8/dx>, al/ax/eax

    ; Example
    in al, 0x21   ; Input byte from 0x21 port to al
    mov dx, 0x379 ; Set dx as port 0x379
    in al, dx     ; Input byte from 0x379 port to al

    out 0x21, al  ; Output byte from al to 0x21 port
    mov dx, 0x378 ; Set dx as port 0x378
    out dx, al    ; Output byte from al to port 0x378
    +

    其中，al/ax/eax根据端口位宽设置，如果对8位端口指定了16位输入/输出，则会连带该端口的下一个端口一并进行输入/输出

    +

    基本概念

    +

    本页的内容基于OSDev Wiki关于实模式的介绍

    +
    +

    实模式是所有的x86处理器都有的一个16位运行模式

    +

    这个模式是为早期的操作系统设计的，它的出现远远早于保护模式

    +

    即使现在的操作系统已经运行在保护模式下了，但是处于兼容性考虑，所有的现代操作系统都需要先从实模式开始运行，然后再切换到保护模式

    +

    在实模式下，CPU只有20根地址线可用，也即可用内存为

    +

    220Byte=1MiB2^{20}Byte = 1MiB +

    +

    为了让16位寄存器能够对全部内存地址空间进行取址，额外引入了段寄存器cs、ss、ds和es、fs、gs，地址的表示由段地址和寄存器表示的偏移地址组合而成

    +

    RealAddress=(SegmentAddress<<4)+ShiftAddressRealAddress = (SegmentAddress << 4) + ShiftAddress +

    +

    段地址保存在段寄存器中，其中es、fs和gs为附加段寄存器，可以由用户自行指定

    本页的内容基于OSDev Wiki关于保护模式的介绍

    +
    +

    保护模式是目前英特尔处理器主流的运行模式，在保护模式中，处理器以32位模式运行，所有的寄存器也都为32位

    +

    为了进入保护模式，操作系统需要在实模式下进行一系列操作：

    +
      +
    • 设置全局描述符表
      • +
    • 关闭中断
      • +
    • 开启第21根地址线
      • +
    • 打开保护模式开关
      • +
    • 执行一次远跳转送入代码段选择子
      • +
    +

    具体的切换方式让我们留到实验中再行讲解

    +

    保护模式之所以叫做保护模式，因为其引入了 “段” 的概念，每一个程序都有它自己的段，一旦程序错误地访问其他段的地址空间，那么CPU就会产生异常

    +

    段 (segment)
    +段实际上是程序员人为划分的一块块连续的内存区域，或者称为地址空间

    +
    +

    误区
    +这里的段概念与实模式的段概念并不相同

    +
    +

    也就是说，可以认为保护模式保护的是地址空间，防止程序代码错误地访问了非它自己的段地址空间，造成越界访问

    +

    为了让CPU知道段的范围，工程师引入了全局描述符表的概念

    +

    全局描述符表可以理解为一段连续的内存，类似于数组，其中存储了全局描述符，每个描述符都对应了一个段的设置

    +

    为了取出对应的全局描述符，就如同用下标从数组中获取数据那样，CPU使用选择子从全局描述符表中获取描述符

    +

    选择子除了包含了取出描述符所需要的下标信息，还包含了一些权限信息等，这些选择子会被存储在段寄存器中

    +

    更多的保护内容
    +除了段保护之外，保护模式实际上还包括了特权级的保护、页保护等
    +例如，保护模式会阻值低特权级代码访问高特权级段空间，会依据特权级限制程序操作等

    +

    操作系统是由中断驱动的

    +
    +

    操作系统的最终目的是完成用户的任务，但很显然，用户不会时时刻刻都有需要操作系统完成的任务，同时，当用户没有向操作系统提交任务的时候，它应当去干点别的而不是傻傻地待在原地等着用户提交任务——这也就是中断的意义

    +

    可以把操作系统想象成一个忙碌的打工人，当你向他提交了任务以后，他便会开始完成你提交的任务。但如果在他进行到一半的时候，你突然又想让他干点别的，该怎么办呢？对了！就是拍拍他的肩膀，说：“伙计，先停停手上的活，把这件事情做了，然后再回来做现在的活儿。”

    +

    中断对于操作系统的作用也正是这样，通过中断，可以让CPU暂停当前正在运行的代码，转而对产生中断的信息进行处理，当处理完后再返回运行原先的代码

    +

    通过中断，可以让操作系统在等待用户/内核打断的同时进行其他的任务，而不需要在原地循环等待用户的下一步指令

    +

    又由于操作系统实质就是无数个 中断-处理-返回 的过程，所以可以说这就是操作系统进行任务的最根本方式，所有的操作都要经由中断来实施，所以可以说 “操作系统是由中断驱动的”

    +

    实验路线

    +

    第零阶段：知识准备

    +

    环境搭建

    +

    在这一步中，需要搭建实验所必需的Linux环境以及虚拟机qemu和C、C++、asm编译器等

    +

    如果读完了 操作系统日志 第一章 的话，那么这一步已经完成了

    +
    +

    汇编语法与操作系统概念

    +

    由于实验的第一部分 ( 编写MBR ) 就需要使用到汇编语法，因此首先需要了解的就是nasm汇编语法

    +

    其次，为了能够对实验有整体的把握，建议先完整阅读 《 操作系统概念（第九版）》 对操作系统有一个整体视角再着手开始实验，这样更有利于落实自己的想法并体验到实验的乐趣所在

    +

    当然，如果是正在跟随课程实验进行，尚不能提前通读整本书的话，也不要担心，因为随着实验的进行也是完全能够循序渐进地认识操作系统的各个概念的

    +

    如果阅读了前文的 前序知识 的话，那么就已经足够可以让我们编写MBR了，让我们继续吧

    +
    +
    +

    第一阶段：启动Kernel

    +

    MBR

    +

    本节需要完成：

    +
      +
    • 使用 中断 加载bootloader
      • +
    • 跳转到bootloader运行
      • +
    +

    bootloader

    +

    本节需要完成：

    +
      +
    • 切换到 保护模式
      • +
    • 从磁盘加载kernelloader
      • +
    • 跳转到kernelloader运行
      • +
    +

    准备

    +

    从这一节开始，将会从asm编程切换到C++和内联汇编组合编程

    +
    +

    为了能够使得操作系统能够方便地组织和使用硬件资源，需要对硬件的接口进行 抽象，编写合适的 驱动

    +

    同时，为了加强代码的可读性，需要将常用的结构包装为 类

    +

    驱动的编写和结构的封装并不需要在这一步就全部完成，而是随着后续代码的编写而逐渐完善

    +
    +

    为了后续实验顺利进行，在这一步需要完成如下驱动：

    +
      +
    • 端口驱动
      • +
    • UART驱动
      • +
    • 磁盘驱动
      • +
    • 显示驱动
      • +
    +

    同时需要完成如下结构体：

    +
      +
    • pagetable：页表
      • +
    • page：页
      • +
    • frame：帧
      • +
    • elf head：ELF头
      • +
    +

    kernelloader

    +

    本节需要完成：

    +
      +
    • 开启 分页机制
      • +
    • 装载 文件系统
      • +
    • 编写elf parser
      • +
    • 从文件系统中读取kernel.o
      • +
    • 使用elf parser解析kernel.o中的 ELF头 并加载内核入内存正确地址处
      • +
    • 跳转到内核运行
      • +
    +

    想要支持多系统？
    +在linux的实现中，多系统通过grub提供引导，关于grub的更多信息可以查看 GNU GRUB的Wiki页面

    +
    +
    +

    第二阶段：内核态

    +

    堆分配器

    +

    实现malloc和free

    +

    从此节开始后，将可以使用malloc和free函数
    +这也意味着同样也可以使用vector等等各种数据结构了，代码的编写自此进入现代化

    +
    +

    页帧分配器

    +

    实现 物理页帧 的管理和分配

    +

    虚拟页管理器

    +

    实现 虚拟页 的管理和分配，实现 虚拟页到物理页的映射

    +

    描述符表

    +

    实现GDT、IDT和TSS的抽象，并初始化描述符表

    +

    中断

    +

    实现 中断处理函数

    +

    本节中会涉及部分用户进程的知识
    +由于用户进程和内核进程都需要使用中断，同时用户进程和内核进程进入中断时在栈上的行为还天杀的不一样
    +为了避免反复编写重复代码，会提前介绍用户进程的行为以及如何编写代码解决其中的问题

    +
    +

    内核进程

    +

    实现 内核进程 以及 进程管理器

    +

    完成本节后，就有了进程调度机制，可以支持并发了

    +
    +
    +

    第三阶段：用户态

    +

    系统调用

    +

    由于用户进程不能直接运行内核相关的代码，因此需要实现系统调用来在对用户进程透明的情况下执行内核相关代码

    +

    用户进程

    +

    在完成系统调用之后，就可以实现 用户进程 了

    +

    Shell

    +

    实现一个 Shell 程序提供用户交互

    +
    +

    从MBR开始编写自己的操作系统

    +

    真正的实验从这里开始

    +
    +

    创建项目

    +

    首先给项目创建一个仓库，不妨叫做MyOS

    +

    之后，为项目创建一个编译用文件夹build，一个存放镜像文件的文件夹run，一个存放所有代码的文件夹src

    +

    由于目前我们需要完成的是操作系统启动的部分，因此本节的代码mbr.asm放置在src/boot文件夹下，同时，为了能够方便地编译项目，在build文件夹下创建项目的makefile文件

    +

    创建完成之后的项目目录看起来就像这样

    +
    1
    2
    3
    4
    5
    6
    7
    .
    ├── build
    │   └── makefile
    ├── run
    └── src
        └── boot
            └── mbr.asm
    +

    Hello World

    +

    Hello World实验作为各大语言的必经之路，在操统实验中自然也是必不可少的

    +

    在尝试输出代码之前，先研究一下怎样让操作系统显示出我们想要的东西…

    +

    通过显存显示内容

    +

    qemu显示屏实际上是按25x80个字符来排列的矩阵，如下所示

    +

    图 1

    +

    为了便于控制显示的内容，IA-32处理器将这个矩阵映射到了内存地址的0xB8000~0xBFFFF处，这段地址被称为显存地址

    +

    在文本模式下，控制器的最小可控制单位为字符。每一个显示字符自上而下，从左到右依次使用显存中的两个字节表示，低字节表示显示的字符，高字节表示字符的颜色属性。
    +例如，黑底白字的H在显存中如下存放：

    + + + + + + + + + + + + + + + + + + + + + + + + + +
    显存地址值含义
    …--
    B800:00010x0F背景色黑色，前景色白色
    B800:00000x48字符H
    +

    每个字符的颜色又由两部分组成，高4位为字符的背景色，低4位为字符的前景色，每个颜色由R、G、B和K/I位组成

    +

    K/I位含义如下

    + + + + + + + + + + + + + + + + + + + + +
    K/I背景色前景色
    0不闪烁深色
    1闪烁亮（浅）色
    +

    字符颜色的对照表如下

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    RGB颜色
    000黑色
    001蓝色
    010绿色
    011青色
    100红色
    101品红
    110棕色
    111白色
    +

    也就是说，0x0F对应的是 背景色为黑色不闪烁，前景色为亮白色的颜色

    +

    于是，记 (x,y)(x, y) 为第 xx 行 yy 列，如果想要在 (x,y)(x, y) 处显示一个字符，则需要做

    +
      +
    1. 计算出该坐标相对于显存起始地址的偏移量
      2. +
    2. 获得字符的颜色值
      3. +
    3. 将字符ASCII码和颜色值放置在显存中
      4. +
    +

    其中，由于一行有80列，每个字符占用两个字节的空间，因此偏移地址计算的公式如下

    +

    Index=2×(x×80+y)Index = 2 \times (x \times 80 + y) +

    +

    之所以要用偏移地址，是因为很容易发现，0xB8000这一个起始地址已经超出了16位所能表示的范围，因此需要引入段地址，这里再回顾一次引用段地址后实际地址的计算公式：

    +

    ActualAddress=(SegmentAddress<<4)+ShiftAddressActualAddress = (SegmentAddress << 4) + ShiftAddress +

    +

    很显然，将段地址设置为0xB800可以让偏移地址从0x0开始取值，因此不妨将段地址0xB800放置在附加段寄存器gs中，然后使用[gs:index]格式进行取址，例如

    +
    1
    2
    mov byte [gs:0], 'H'
    mov byte [gs:1], 0x0F
    +

    就是将黑底白字的H显示在坐标 (0,0)(0, 0)处

    +

    通过中断显示内容

    +

    除了使用显存赋值这一操作来显示字符，在实模式下还提供了另一种显示字符的方式——中断

    +

    中断的调用涉及了四个部分：

    +
      +
    1. 设置中断参数：参数一般为存储在bx、cx和dx寄存器或是它们的高低位中的值
      2. +
    2. 设置中断功能：一种中断调用可以实现很多不同的功能，具体要调用的功能一般通过ax或是ah指定
      3. +
    3. 调用中断：使用int指令和对应的中断向量号调用中断
      4. +
    4. 获取返回值：中断函数如果有返回值的话一般是放在寄存器中，所以要从寄存器中获取返回值
      5. +
    +

    BIOS提供了很多中断函数，中断向量号和它们的功能可以查看 OSDev Wiki中关于BIOS的页面

    +

    在本次实验中我们暂时只关注int 10h这个函数，它提供了光标相关的操作，对应的参数和返回值可以参考 Wikipedia 中关于光标中断的页面
    +为了方便查阅，显示字符所需要用到功能在下表列出

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    功能功能号参数返回值
    设置光标位置AH=02HBH：页码
    DH：行，DL：列    		-
    获取光标位置AH=03HBX：页码AX=0
    CH：行扫描开始，CL：行扫描结束
    DH：行，DL：列
    实验中一般只需要用到DH和DL
    在光标位置写入字符AH=09HAL：字符，BL：颜色
    BH：页码，CX：输出字符个数    		-
    +

    所以在 (x,y)(x, y) 处写入字符需要如下步骤：

    +
      +
    1. 设置光标位置为 xx 行 yy 列
      2. +
    2. 设置字符颜色等参数
      3. +
    3. 在光标位置写入字符
      4. +
    +

    例如，在 (0x1C,0x03)(0x1C, 0x03)处写入黑底白色的字符H操作为

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    move_cursor:
      ; Set cordinates
      mov dh, 0x1C
      mov dl, 0x03

      ; Set interrupt function
      mov ah, 0x02  ; AH=02H indicates setting the position of cursor

      ; Call interrupt function
      int 0x10

    output_character:
      ; Set character properties
      mov al, 'H'   ; Character: 'H'
      mov bl, 0x0F  ; Background: black & Foreground: white
      mov cx, 0x01  ; Output num: 1

      ; Set interrupt function
      mov ah, 0x09  ; AH=09H indicates outputting character at cursor position

      ; Call interrupt function
      int 0x10
    +

    编写MBR

    +

    回顾：MBR的加载
    +计算机加电启动并完成自检之后，BIOS会根据引导顺序检查磁盘首扇区 （也即存放MBR的扇区） 是否可以启动
    +如果可以启动，BIOS会将这512字节加载到0x7C00处开始执行
    +此时，CPU运行在 实模式 下

    +
    +

    为了让编译器能够正确理解 “我们是在编写MBR” 这件事，需要使用一些汇编的伪指令告知编译器：

    + +

    翻译成asm语言如下

    +
    1
    2
    [org 0x7C00]
    [bits 16]
    +

    之后，需要对寄存器进行初始化，避免为初始化的段地址影响后续的取址操作
    +需要注意的是，段寄存器只能通过ax寄存器赋值，所以可以先将ax置0，然后再通过ax将段寄存器置0

    +

    陷阱：不要初始化cs
    +在初始化段寄存器的时候，通过实验发现，ds, ss, es, fs, gs都可以正常进行置0操作
    +但是如果对cs进行置0，则会导致代码出现意料之外的行为
    +所以不要将cs寄存器初始化

    +
    +
    1
    2
    3
    4
    5
    6
    7
    ; Initialize registers
    xor ax, ax  ; ax = 0
    mov ds, ax  ; ds = 0
    mov ss, ax  ; ss = 0
    mov es, ax  ; es = 0
    mov fs, ax  ; fs = 0
    mov gs, ax  ; gs = 0
    +

    此时栈指针寄存器sp还没有被初始化，由于栈是从高地址向低地址增长的，所以需要给栈分配一段可以向下增长的空间
    +这一段空间的选择相对自由，但是由于MBR对栈空间的使用较小，并且当启动到后续阶段的时候也可以再移动栈指针，所以不妨将栈指针放置在0x7C00处让其向下增长

    +
    1
    2
    ; Initialize stack pointer
    mov sp, 0x7C00
    +

    之后使用显存显示内容的方式来完成Hello World!字串的输出

    +
    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
    ; Print something
    mov ax, 0xB800
    mov gs, ax  ; Set video segment as 0xB800

    mov si, 0   ; Current character index
    print:
        mov dl, byte [_msg + si]    ; Fetch character
        cmp dl, 0                   ; Exit if character is '\0'
        je  print_exit
        inc si                      ; index += 1
        ; Calculate cordinate in vga memory
        ; Shift = 2 * (80 * row  + col)
        mov ax, word [_row] 
        imul ax, 80
        add ax, word [_col]
        imul ax, 2
        ; Copy character to memory
        mov bx, ax
        mov byte [gs:bx], dl        ; Character to be printed
        mov byte [gs:bx + 1], 0x0F  ; Black background with white foreground
        ; Set new cordinate
        add word [_col], 1
        mov ax, word [_col]
        cmp ax, 80
        jne add_row_exit
        add word [_row], 1          ; move cursor to next row if col == 80
        mov word [_col], 0
        add_row_exit:
        ; Reture to top
        jmp print
    print_exit:

    ; Halt here
    jmp $

    ; Variables
    _row    dw 0
    _col    dw 0
    _msg    db 'Hello World!',
            db 0
    +

    陷阱：不要将数据放置在代码中间或者前部
    +BIOS从0x7C00处开始执行代码，其并不区分内存中存储的二进制码究竟是数据还是指令，因此如果将数据放置在代码前面，可能会让CPU误认为数据是代码从而被执行，产生无法预料的错误，这类错误往往很难通过调试发现

    +
    +

    不要让代码掉进 “虚无”
    +可以在代码后面添加jmp $，其中$的意思是当前语句的地址，这句指令无限跳转到其自身执行
    +这阻止了CPU继续执行这句代码之后的内容，因为后面可能是数据空间或是虚无，它们同样可能被解读成错误的指令从而产生无法预料的错误

    +
    +

    最后，由于还没有开始做文件系统和磁盘分区，不妨将MBR后续字节填充零，使用伪指令times来重复填充，$ - $$很容易解读出其意译为当前地址减去文件起始地址的差

    +
    1
    2
    3
    4
    5
    ; Fill 0 before byte 447
    times 446 - ($ - $$) db 0

    ; Fill 0 (temporary) for partition table
    times 510 - ($ - $$) db 0
    +

    完整的mbr.asm文件如下

    +
    +
    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
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    [org 0x7C00]  ; Indicates codes below starts at 0x7C00
    [bits 16]   ; Indicates codes below run in 16-bit mode

    ; Initialize registers
    xor ax, ax  ; ax = 0
    mov ds, ax  ; ds = 0
    mov ss, ax  ; ss = 0
    mov es, ax  ; es = 0
    mov fs, ax  ; fs = 0
    mov gs, ax  ; gs = 0

    ; Initialize stack pointer
    mov sp, 0x7C00

    ; Print something
    mov ax, 0xB800
    mov gs, ax  ; Set video segment

    mov si, 0
    print:
        mov dl, byte [_msg + si]
        cmp dl, 0
        je  print_exit
        inc si
        ; Calculate cordinate in vga memory
        mov ax, word [_row]
        imul ax, 80
        add ax, word [_col]
        imul ax, 2
        ; Copy character to memory
        mov bx, ax
        mov byte [gs:bx], dl    ; Character to be printed
        mov byte [gs:bx + 1], 0x0F  ; Black background with white foreground
        ; Set new cordinate
        add word [_col], 1
        mov ax, word [_col]
        cmp ax, 80
        jne add_row_exit
        add word [_row], 1
        mov word [_col], 0
        add_row_exit:
        ; Reture to top
        jmp print
    print_exit:

    ; Halt here
    jmp $

    ; Variables
    _row    dw 0
    _col    dw 0
    _msg    db 'Hello World!',
            db 0

    ; Fill 0 before byte 447
    times 446 - ($ - $$) db 0

    ; Fill 0 (temporary) for partition table
    times 510 - ($ - $$) db 0

    ; Magic number
    dw 0xAA55
    +

    编写makefile

    +

    Makefile Tutorial
    +如果对Makefile语法尚不熟悉，可以前往 Makefile Tutorial 页面了解

    +
    +

    为了让项目能够顺利地运行起来，需要编写Makefile文件。在默认已经了解Makefile语法的前提下，简要介绍从MBR启动所需要的各个文件以及它们的依赖关系

    + + + + + + + + + + + + + + + + + + + + + + + + + +
    文件作用依赖关系
    hd.img硬盘文件
    QEMU会尝试从这个文件的首扇区加载MBR启动    		mbr.bin
    需要将MBR写入磁盘才能够启动
    mbr.binMBR编译后的二进制文件mbr.asm
    mbr.asmMBR源文件-
    +

    根据这些依赖关系，可以写出Makefile文件

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

    SRC_PATH := ../src
    RUN_PATH := ../run

    .PHONY:
    build: mbr.bin
      qemu-img create $(RUN_PATH)/hd.img 10m
      dd if=mbr.bin of=$(RUN_PATH)/hd.img bs=512 count=1 seek=0 conv=notrunc

    %.bin: $(SRC_PATH)/boot/%.asm
      $(ASM_COMPILER) -o $@ -f bin $^

    .PHONY:
    clean:
      rm -f *.o* *.bin
      rm -f $(RUN_PATH)/*.img

    .PHONY:
    run:
      qemu-system-i386 -hda $(RUN_PATH)/hd.img -vga virtio -serial null -parallel stdio -no-reboot
    +

    运行和结果

    +

    进入项目目录下的build/目录

    +
    1
    make clean build run
    +

    可以首先清除原先生成的文件，重新构建并且运行
    +运行的结果如下

    +

    图 2

    +

    完成本章
    +下一章中，将会编写bootloader，从mbr中加载bootloader并且启动，最后在bootloader中让CPU进入保护模式
    +如果准备好了的话，就让我们进入下一章吧！

    +
    diff --git a/source/_posts/os-journal-vol-3.md b/source/_posts/os-journal-vol-3.md new file mode 100644 index 0000000..204a467 --- /dev/null +++ b/source/_posts/os-journal-vol-3.md @@ -0,0 +1,806 @@ +--- +title: 操统实验日志 第三章 从实模式到保护模式 +date: 2022-07-19 13:36:30 +description: 在本章的第一部分中，将会介绍读取硬盘的CHS方式、LBA方式以及如何通过 in、out 指令读写硬盘，之后会将上一章输出 Hello World! 的代码移植到 BootLoader 中，并且从 MBR 中加载并跳转到编写的 BootLoader 执行。在第二部分中，会回顾保护模式的概念并介绍进入保护模式的四个步骤，并在开启保护模式之后输出第二个 Hello World。 +tags: + - 操作系统 + - 大学 +categories: + - 技术 +--- + +

    关于本章

    +

    在本章的第一部分中，将会介绍读取硬盘的CHS方式、LBA方式以及如何通过in、out指令读写硬盘，之后会将上一章输出Hello World!的代码移植到BootLoader中，并且从MBR中加载并跳转到编写的BootLoader执行

    +

    在第二部分中，会回顾保护模式的概念并介绍进入保护模式的四个步骤，并在开启保护模式之后输出第二个Hello World

    +

    第一次跃进：从MBR跳转到BootLoader

    +

    MBR只有512字节的大小，甚至如果除去分区表，只有四百多字节的大小，这个大小稍微复杂一些的程序就难以运行了，更不要说是把全部的操作系统都放在里面了

    +

    因此，目前的首要任务就是 突破512字节的限制，从而能够让我们着手编写更复杂的程序，其实，聪明的工程师很早就提出了一个可行的解决方案：在MBR里面把另一段更大的程序加载到内存里面，之后跳转到加载的地址去执行，这个 “更大的程序” 就是我们本节要编写的BootLoader，它在编译之后会被烧录到硬盘镜像中指定的扇区里，MBR要做的事情就是从这些扇区里面把我们编写的BootLoader加载出来放在内存里，然后跳转到加载的内存地址处执行BootLoader的代码

    +

    为什么不直接从MBR跳转到内核运行？
    +从上一章的实验路线中可以看到，在加载内核之前有许多需要准备的工作，包括开启虚拟分页机制以及文件系统的装载
    +很显然这些并不能在MBR中完成，所以需要在MBR和内核中间添加一些步骤，作为启动内核前的准备操作

    +
    +

    简述CHS模式

    +

    CHS全称为 Cylinder-head-sector，是早期用来定位硬盘上扇区的一种方式

    +

    在CHS中，扇区通过不同的 柱面 (Cylinder)、磁头 (Head) 和 扇区 (Sector) 指定，除此之外，在CHS中还有一个额外的概念 磁道 (Track) ，下面简要介绍这四个概念的含义

    + +

    如果还不能够完全理解，可以查看Wikipedia关于CHS模式的页面中精妙的配图如下

    +

    图 1

    +

    简述LBA模式

    +

    LBA模式全称为 Logical Block Addressing，顾名思义，就是通过逻辑扇区号去寻址物理扇区号，具体的寻址方式则是对用户透明的

    +

    在LBA模式下，不存在像CHS那样复杂的概念，硬盘的扇区被看作是线性的并从0扇区开始编号，当使用LBA扇区号进行取址的时候，存储设备会自动转换成对应的柱面、磁头和扇区进行读取，用户不需要关心这部分的实现

    +

    陷阱：CHS和LBA模式的扇区编号不同
    +在CHS模式下，扇区从1开始编号，而在LBA模式下，扇区从0开始编号

    +
    +

    通过CHS编号来计算LBA编号可以使用如下公式，其中HPC为柱面中的磁头数 Heads per Cylinder，SPT为每个磁道中的扇区数 Sectors per Track

    +

    LBA=(C×HPC+H)×SPT+(S−1)LBA = (C \times HPC + H) \times SPT + (S - 1) +

    +

    同样，LBA模式也可以通过下述公式转换为CHS编号

    +

    {  C=LBA÷(HPC×SPT)H=(LBA÷SPT)  mod  HPCS=(LBA  mod  SPT)+1\left\{ + \begin{aligned} + \; &C = LBA \div (HPC \times SPT)\\ + &H = (LBA \div SPT)\;mod\;HPC\\ + &S = (LBA\;mod\;SPT) + 1 + \end{aligned} +\right. +

    +

    在LBA模式下通过端口读写磁盘

    +

    接口和模式
    +在实验中使用的接口为ATA，使用PIO模式进行访问

    +
    +

    ATA PIO模式
    +ATA PIO mode的更多信息可以查看OSDev中关于这一主题的页面

    +
    +

    ATA、PATA、SATA的区别
    +关于ATA、PATA、SATA以及ATA PIO之间的区别，可以查看Reddit中关于这个主题的讨论

    +
    +

    了解了硬盘的寻址模式之后，就可以开始着手从磁盘里读取数据了，在实验中我就采用了更为 无脑 简单的LBA28模式

    +

    LBA28
    +LBA28指的是使用28位来表示逻辑扇区的编号

    +
    +

    既然要从磁盘读取数据，那就自然要告诉磁盘 读数据、去哪读和读多少，端口就在这个过程中充当了信使的角色，我们通过向端口发送数据，告诉磁盘读取地址和读取数量，等候磁盘完成后再从端口接收数据

    +

    在磁盘读的操作中，要用到的端口及其描述如下

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    端口号端口数据传输方向作用 (LBA28)描述位长 (LBA28)
    0x1F0读/写数据寄存器硬盘读出/要写入的数据16-bit
    0x1F1读错误码寄存器存储执行的ATA指令所产生的错误码8-bit
    0x1F1写功能寄存器用来指定特定指令的接口功能8-bit
    0x1F2读/写扇区数寄存器存放需要读写的扇区数量8-bit
    0x1F3读/写起始扇区寄存器存放起始扇区0-7位8-bit
    0x1F4读/写起始扇区寄存器存放起始扇区8-15位8-bit
    0x1F5读/写起始扇区寄存器存放起始扇区16-23位8-bit
    0x1F6读/写磁盘、起始扇区寄存器选择磁盘和访问模式
    存放起始扇区24-27位    		8-bit
    0x1F7读状态寄存器读取当前磁盘状态8-bit
    0x1F7写指令寄存器传送ATA指令8-bit
    +

    其中，部分端口的位作用比较复杂，部分位在实验中也不需要留意，使用*号注明

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    端口号位缩写作用
    0x1F60-3-在LBA模式中，指定其起始扇区号的24-27位
    0x1F64DRV指定磁盘
    0：主硬盘
    1：从硬盘
    0x1F651始终置位
    0x1F66LBA指定访问模式
    0：CHS模式
    1：LBA模式
    0x1F671始终置位
    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    端口号位缩写作用
    0x1F7 (Read)0ERR指示是否有错误发生，通过发送新指令可以清除该位
    0x1F7 (Read)1*IDX索引，始终置为0
    0x1F7 (Read)2*CORR修正数据，始终置位0
    0x1F7 (Read)3DRQ0：硬盘还不能交换数据
    1：硬盘存在可以读取的数据或是可以写入数据
    0x1F7 (Read)4*SRV重叠模式服务请求
    0x1F7 (Read)5*DF驱动器故障错误
    0x1F7 (Read)6*RDY0：驱动器发生了减速或是错误
    1：驱动器运转正常
    0x1F7 (Read)7BSY忙位
    0：空闲
    1：忙
    +

    了解了各个端口的作用后，如何从硬盘读取数据似乎就是显而易见的了：

    +
      +
    1. 设置起始扇区号
      2. +
    2. 设置读取的扇区数量
      3. +
    3. 设置磁盘和访问模式
      4. +
    4. 检测状态位，等待硬盘就绪
      5. +
    5. 从端口读取数据
      6. +
    +

    为了方便代码重用 （虽然MBR的代码也不会重用了），在实验中将读取硬盘的功能包装成一个汇编函数进行调用

    +

    NASM中的函数调用

    +

    调用函数前，通过将参数压栈的方式传递参数
    +使用call tag调用函数，在执行call指令时会将下一条指令地址压入栈顶
    +在函数内部，需要使用pushad为主调函数保存寄存器的值
    +在函数结束后，使用ret返回，在执行ret指令时会取出栈顶值并跳转到该值处执行
    +调用函数后，通过执行add sp, <imm>操作将栈指针上移，从栈上删除传递的参数

    +
    +

    令函数名为read_sectors，并假定主调函数向其传递四个参数值startSector[15:0]、startSector[27:16]、sectorCount和targetAddress，可以据此先写出函数体

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    read_sectors:
      ; Imagined Stack Appearance
      ; ------------------------- (High)
      ; targetAddress
      ; sectorCount
      ; startSector[27:16]
      ; startSector[15:0]
      ; ret
      ; ------------------------- (Lo)
      ; Save state
      push sp
      mov bp, sp
      pushad

      ; Fill function here

      ; Restore state
      popad
      pop sp
      ; Return
      ret
    +

    之后从栈上依次取出起始扇区号并发送到端口0x1F3~0x1F6

    +

    陷阱：注意正确设置0x1F6端口高4位
    +0x1F6端口高四位包括了主从硬盘位和访问模式位
    +如果误使用CHS模式读取硬盘，由于CHS扇区从1开始编号，会导致读出错误的扇区

    +
    +

    陷阱：栈上的字长为2字节
    +在16位模式中栈上的字长为2字节，因此使用bp在栈上取数据时步进为2而不是4
    +也就是，如果使用上文中的函数开头，第一个参数的为word [bp + 2 * 2]

    +
    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    mov bx, word [bp + 2 * 2]   ; bx = startSector[15:0]
    mov al, bl  ; al = startSector[7:0]
    mov dx, 0x1F3

    out dx, al
    mov al, bh  ; al = startSector[15:8]
    mov dx, 0x1F4
    out dx, al

    mov bx, word [bp + 3 * 2]   ; bx = startSector[27:16]
    and bx, 0x0FFF              ; bx[15:12] = 0
    or  bx, 0xE000              ; bx[15:12] = 0b1110 (LBA method)
    mov al, bl  ; al = startSector[23:16]
    mov dx, 0x1F5
    out dx, al

    mov al, bh  ; al = 0xE:startSector[27:24]
    mov dx, 0x1F6
    out dx, al
    +

    然后通过0x1F2端口设置读取的扇区数量

    +
    1
    2
    3
    mov al, byte [bp + 4 * 2]    ; al = sectorCount
    mov dx, 0x1F2
    out dx, al
    +

    向0x1F7端口发送0x20指令请求硬盘读

    +
    1
    2
    3
    mov dx, 0x1F7
    mov al, 0x20
    out dx, al
    +

    在发送读请求后，通过循环检测0x1F7端口的0、3、7位等待硬盘就绪，就绪的标志为这三位依次为0、1、0

    +

    陷阱：记得等待硬盘就绪
    +在从端口读取数据前，一定要等待硬盘就绪，不然会读出错误的数据

    +
    +
    1
    2
    3
    4
    5
    6
    .wait_disk:
        mov dx, 0x1F7
        in  al, dx
        and al, 0x89
        cmp al, 0x08
        jnz .wait_disk
    +

    最后，从0x1F0端口读取数据

    +

    0x1F0端口为16位端口，因此一次可以读取两个字节，总的读取次数为

    +

    LoopCount=SectorCount×512÷2=SectorCount×256\begin{aligned} +LoopCount &= SectorCount \times 512 \div 2 \\ + &= SectorCount \times 256 +\end{aligned} +

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    xor ax, ax                  ; Set ax = 0
    mov al, byte [bp + 4 * 2]   ; ax = sectorCount
    imul ax, 256                ; ax = word count
    mov bx, word [bp + 5 * 2]   ; bx = targetAddress
    mov si, 0                   ; shift = 0
    mov cx, ax                  ; set loop = ax = word count
    .write_word:
        mov dx, 0x1F0
        in  ax, dx              ; read 2 bytes from port
        mov word [bx + si], ax  ; write data to memory
        add si, 2               ; add 2 bytes for each read operation
        loop .write_word
    +

    所以完整的读取函数为

    +
    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
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    ; Loader sector function
    ; Notice: Loads using LBA method
    read_sectors:
        ; push targetAddr
        ; push sectorCount
        ; push startSector[27:16]
        ; push startSector[15:0]
        ; push ret
        push sp
        mov bp, sp
        pushad

        mov bx, word [bp + 2 * 2]   ; bx = startSector[15:0]
        mov al, bl  ; al = startSector[7:0]
        mov dx, 0x1F3
        out dx, al
        mov al, bh  ; al = startSector[15:8]
        mov dx, 0x1F4
        out dx, al
        
        mov bx, word [bp + 3 * 2]   ; bx = startSector[27:16]
        and bx, 0x0FFF              ; bx[15:12] = 0
        or  bx, 0xE000              ; bx[15:12] = 0b1110 (LBA method)
        mov al, bl  ; al = startSector[23:16]
        mov dx, 0x1F5
        out dx, al
        mov al, bh  ; al = 0xE:startSector[27:24]
        mov dx, 0x1F6
        out dx, al

        mov al, byte [bp + 4 * 2]    ; al = sectorCount
        mov dx, 0x1F2
        out dx, al

        mov dx, 0x1F7
        mov al, 0x20
        out dx, al

        .wait_disk:
            mov dx, 0x1F7
            in  al, dx
            and al, 0x89
            cmp al, 0x08
            jnz .wait_disk

        xor ax, ax
        mov al, byte [bp + 4 * 2]   ; ax = sectorCount
        imul ax, 256    ; ax = word count
        mov bx, word [bp + 5 * 2]   ; bx = targetAddress
        mov si, 0       ; shift = 0
        mov cx, ax      ; set loop = ax
        .write_word:
            mov dx, 0x1F0
            in  ax, dx
            mov word [bx + si], ax
            add si, 2
            loop .write_word

        popad
        pop sp
        ret
    +

    加载BootLoader并跳转

    +

    为了验证上一节中读取硬盘函数的正确性，现在需要在项目中创建BootLoader，由于目前我们还不打算在BootLoader中完成很复杂的任务，所以就先将上一节中打印’Hello World!'的代码移植到BootLoader中，然后尝试从MBR加载并跳转到BootLoader执行，看看能否正常运行

    +

    首先我们需要扩充我们的项目结构：

    + +

    扩充后的项目结构大致像这样

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    .
    ├── build
    │   └── makefile
    ├── readme.md
    ├── run
    │   └── hd.img
    └── src
        └── boot
            ├── boot.inc
            ├── bootloader.asm
            └── mbr.asm
    +

    在开始移植之前，需要先确认BootLoader的起始地址以及它的大小，这涉及到内存地址的安排

    +

    在操作系统内核设计的过程中，内存规划是一件令人苦恼的事情，但同时也是一件自由的事情，只要不发生溢出和重叠之类的问题，将内容放置在哪里是一个相对主观的事情

    +

    这里我将BootLoader直接放置在MBR后面，占用4个扇区的大小，内存的安排如下

    + + + + + + + + + + + + + + + + + + + + + + + +
    用途起始地址终止地址扇区数
    MBR0x7C000x7E001
    BootLoader0x7E000x86004
    +

    完成了内存规划之后，就可以将常数写入头文件中了

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    ; Constants used during the boot procedure

    ; MBR
    BOOTLOADER_SECTOR_START_15_0 equ 1
    BOOTLOADER_SECTOR_START_27_16 equ 0
    BOOTLOADER_SECTOR_COUNT equ 4
    BOOTLOADER_LOAD_ADDRESS equ 0x7E00

    ; BootLoader
    GDT_START_ADDRESS equ 0x9000
    ZERO_SELECTOR equ 0x00
    KERNEL_CODE_SELECTOR equ 0x08
    KERNEL_DATA_SELECTOR equ 0x10
    KERNEL_STACK_SELECTOR equ 0x18
    GDT_SIZE equ 4
    +

    打印Hello World!代码的移植步骤就比较简单了，直接复制粘贴入bootloader.asm即可，不过需要注意的是要修改一下头部伪代码中的[org 0x7C00]为BootLoader的起始地址[org 0x7E00]

    +
    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
    %include "boot.inc"
    [org 0x7E00]
    [bits 16]

    ; Print something
    mov ax, 0xB800
    mov gs, ax  ; Set video segment

    mov si, 0
    print:
        mov dl, byte [_msg + si]
        cmp dl, 0
        je  print_exit
        inc si
        ; Calculate cordinate in vga memory
        mov ax, word [_row]
        imul ax, 80
        add ax, word [_col]
        imul ax, 2
        ; Copy character to memory
        mov bx, ax
        mov byte [gs:bx], dl    ; Character to be printed
        mov byte [gs:bx + 1], 0x0F  ; Black background with white foreground
        ; Set new cordinate
        add word [_col], 1
        mov ax, word [_col]
        cmp ax, 80
        jne add_row_exit
        add word [_row], 1
        mov word [_col], 0
        add_row_exit:
        ; Reture to top
        jmp print
    print_exit:

    ; Halt here
    jmp $

    ; Variables
    _row    dw 0
    _col    dw 0
    _msg    db 'Hello World!',
            db 0

    times 2048 - ($ - $$) db 1
    +

    之后，对mbr.asm中的代码进行修改

    +

    向其中添加read_sectors函数并且调用read_sectors函数

    +
    1
    2
    3
    4
    5
    6
    7
    ; Read bootloader
    push BOOTLOADER_LOAD_ADDRESS
    push BOOTLOADER_SECTOR_COUNT
    push BOOTLOADER_SECTOR_START_27_16
    push BOOTLOADER_SECTOR_START_15_0
    call read_sectors
    add sp, 8
    +

    跳转到BootLoader的起始地址

    +
    1
    2
    ; Jump to bootloader
    jmp BOOTLOADER_LOAD_ADDRESS
    +

    最后，修改makefile文件，由于添加了两个文件，依赖关系也产生了变化，新的依赖关系如下

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    文件作用依赖关系
    hd.img硬盘文件
    QEMU会尝试从这个文件的首扇区加载MBR启动    		mbr.bin
    bootloader.bin
    mbr.binMBR编译后的二进制文件mbr.asm
    boot.inc
    bootloader.binBootLoader编译后的二进制文件bootloader.asm
    boot.inc
    mbr.asmMBR源文件-
    bootloader.asmBootLoader源文件-
    boot.inc头文件-
    +

    根据新的依赖关系，可以编写新的makefile文件如下，其中除了添加了新的依赖文件编译规则外，还添加了对头文件路径的指定

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    ASM_COMPILER := nasm

    SRC_PATH := ../src
    RUN_PATH := ../run
    INCLUDE_PATH := $(addprefix -I, $(dir $(shell find '$(SRC_PATH)' -name '*.inc')))

    .PHONY:
    build: mbr.bin bootloader.bin
      qemu-img create $(RUN_PATH)/hd.img 10m
      dd if=mbr.bin of=$(RUN_PATH)/hd.img bs=512 count=1 seek=0 conv=notrunc
      dd if=bootloader.bin of=$(RUN_PATH)/hd.img bs=512 count=4 seek=1 conv=notrunc

    %.bin: $(SRC_PATH)/boot/%.asm
      $(ASM_COMPILER) -o $@ -f bin $(INCLUDE_PATH) $^

    .PHONY:
    clean:
      rm -f *.o* *.bin
      rm -f $(RUN_PATH)/*.img

    .PHONY:
    run:
      qemu-system-i386 -hda $(RUN_PATH)/hd.img -vga virtio -serial null -parallel stdio -no-reboot
    +

    运行的方式与上一章相同，进入build/目录下执行make clean build run即可以对代码进行编译和运行

    +

    运行的结果应该与上一章一样，在屏幕的第一行打印出Hello World!字样

    +

    图 2

    +

    在BootLoader中开启保护模式

    +

    知识准备

    +

    保护模式

    +

    保护模式是目前英特尔处理器主流的运行模式，在保护模式中，处理器以32位模式运行，所有的寄存器也都为32位，因此程序可以访问到232=4GiB2^{32} = 4GiB的内存空间

    +

    保护模式提出了 段 的概念，在CPU产生地址以后，会判断这个地址是否超出了段所规定的地址，从而避免程序之间的越界访问

    +

    除此之外，保护模式还包括了特权级保护等，在后面的实验中会逐个涉及

    +
    +

    上面提到，在保护模式中提出了段的概念，在保护模式中运行的各种代码都需要声明自己所使用的段，并且由CPU监视地址的访问是否越界。那么，代码是如何告诉CPU自己所使用的段信息，CPU又是如何知道段的界限的呢？

    +

    实际上，为了能够让CPU得知段的具体信息，需要在内存中分配一段地址空间，在其中放置关于各个段的说明信息，这部分空间就被叫做全局描述符表GDT (Global Descriptor Table)

    +

    全局描述符表的起始地址与它的大小组合成一段48位长度的数据提供给CPU作为查询全局描述符表基地址的依据，放置在CPU中的GDTR寄存器中，GDTR的结构如下

    + + + + + + + + + + + + + + + + + +
    位区间描述
    [48:16]基地址 (Offset) [31:0]
    [15:0]大小 (Size) [15:0]
    +

    其中，大小由最多能够放入的描述符个数Count指定

    +

    Size=Count×8−1Size = Count \times 8 - 1 +

    +

    全局描述符表看起来就像一个数组，其存放的都是64位长度的元素，每一个元素都用来描述一个段的信息，被称作段描述符 (Segment Descriptor)，全局描述符表中的第一个元素始终为空描述符，从第二个元素开始可以由程序定义

    +

    对于段描述符而言，它由七个部分组成，结构如下

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    位区间描述
    [63:56]起始地址 (Base) [31:24]
    [55:52]标志位 (Flags) [3:0]
    [51:48]段界限 (Limit) [19:16]
    [47:40]访问控制位 (Access Byte) [7:0]
    [39:32]起始地址 (Base) [23:16]
    [31:16]起始地址 (Base) [15:0]
    [15:0]段界限 (Limit) [15:0]
    +

    其中，访问控制位又分为七个不同的部分，其结构和作用如下

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    位缩写描述
    0A访问位 (Accessed bit)
    0：段未被访问
    1：段在上次清除这个访问位后被访问过
    1RW读写权限位 (Readable/Writable bit)
    代码段：0不可读，1可读，始终不可写
    数据段：0不可写，1可写，始终可读
    2DC增长方向/一致性标志位 (Direction/Conforming bit)
    代码段：0只能由DPL中指定的特权级执行，1代表DPL中指定可执行的最高特权级
    数据段：0段向高地址增长，1段向低地址增长
    3E可执行位 (Executable bit)
    0：不可执行，为数据段
    1：可执行，为代码段
    4S描述符类型位 (Descriptor type bit)
    0：系统段，例如TSS
    1：代码段或是数据段
    5-6DPL描述符特权级 (Descriptor privilege level field)
    0：最高特权级（内核）
    3：最低特权级（用户）
    7P存在位 (Present bit)
    0：该描述符不可用 (invalid)
    1：描述符可用
    +

    段描述符的标志位则使用三个不同的标志设置了段的粒度、位模式

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    位缩写描述
    0Reserved保留位，始终置0
    1L长模式标志位 (Long-mode code flag)
    0：位模式由DB位指定
    1：段描述的位64位代码段
    2DB位模式位 (Size flag)
    0：描述符对应16位保护模式段
    1：描述符对应32位保护模式段
    置位时L位应为0
    3G粒度标志位 (Granularity flag)
    0：描述符中的段界限按照字节单位计算
    1：描述符中的段界限按照4KiB单位计算
    +

    在了解了段描述符各个位的作用后，CPU又是如何通过这些地址和标志位去判断地址的合法性的呢？要明确这个问题，就需要首先知道CPU是如何生成地址的

    +

    进入保护模式之后，每当CPU生成一个地址，它实际上生成的是相对于段的偏移地址Offset，CPU同时还会通过上文中提到的段选择子从全局描述符表中取出段的基地址Base，之后CPU中的地址变换部件会判断偏移地址的合法性，并组合偏移地址和基地址得到真实的物理地址Address，这个最后的物理地址才会用于访问内存数据

    +

    也就是说，Address、Base和Offset之间存在如下关系

    +

    Address=Base+OffsetAddress = Base + Offset +

    +

    而CPU对地址合法性的检验，实际上就是在做Offset和段描述符中界限Limit之间关系的判断，当然，由于粒度Granularity的引入，在计算实际的界限时还需要掺入粒度单位

    +

    对于向上增长的段，它的偏移地址需要满足

    +

    0≤Offset≤Limit×Granularity0 \le Offset \le Limit \times Granularity +

    +

    这个很好理解，因为 00 代表着段中第一个字节的地址，而 Limit×GranularityLimit \times Granularity 代表段中最后一个字节的地址，偏移量需要介于这两者之间，才是合法的访问

    +

    陷阱：粒度不是直接进行乘4KiB的操作
    +实际上，Limit×GranularityLimit \times Granularity 并不像我们想的那样将界限直接左移12位，而是相当于Limit << 12 | 0xFFF
    +也就是说，在4KiB粒度下，0xFFFFF的界限实际对应着0xFFFFFFFF，0x00000对应着0x00000FFF

    +
    +

    对于向下增长的段，则稍微有些不一样，一个比较容易理解的阐述是，对于使用相同基址和界限的向上增长段，其合法地址在向下增长的段中不合法，其不合法的地址在向下增长的段中合法，如果使用公式来更严谨的解释这一说法，则偏移地址需要满足

    +

    Limit×Granularity+1≤Offset≤0xFFFFFFFF  (0xFFFF  for  16  bit)Limit \times Granularity + 1 \le Offset \le 0\mathtt{x}FFFFFFFF\;(0\mathtt{x}FFFF\;for\;16\;bit) +

    +

    举一个例子，假设需要在16位模式下设置一个1KiB栈段，其最高地址为0xFFFF，则其最低地址为0xFC00，大家可能很快就能想到，将基地址设置为0x0000并设置界限为0xFC00既可以描述这个栈段

    +

    但且慢，注意到偏移地址的最低合法地址为 Limit×Granularity+1Limit \times Granularity + 1，如果界限设置为0xFC00，则最低合法地址为 0x0000+0xFC00+1=0xFC010\mathtt{x}0000 + 0\mathtt{x}FC00 + 1 = 0\mathtt{x}FC01，栈的大小则不是1KiB，而是1KiB - 1了

    +

    因此，界限应该设置为0xFBFF才能让栈段的可用地址为1KiB

    +

    全局描述符表不仅可以存储段描述符
    +在之后的章节中，会了解到全局描述符表中不仅可以存放段描述符，还可以存放其他长度相同的描述符，例如任务状态段TSS (Task State Segment)，这将会在实现用户进程的章节介绍

    +
    +

    既然是数组，那就意味着可以通过下标（索引）来取出某个位置上的元素，CPU也正是这么做的，当一个程序向CPU声明自己所使用的段时，它实际上是向CPU提供了一个索引，这个16位索引中存储了其所使用的段在全局描述符表中的下标以及特权级信息（将会在用户进程的实现中介绍），被称作段选择子 (Segment Selector)

    +

    段选择子由其对应的段在全局描述符表中的索引、描述符表类型以及特权级构成，其结构如下

    + + + + + + + + + + + + + + + + + + + + + +
    位区间描述
    [15:3]索引 (Index) [12:0]
    [2:2]描述符表类型 (TI)
    0：使用全局描述符表 (GDT)
    1：使用局部描述符表 (LDT)
    [1:0]特权级 (RPL) [1:0]
    +

    我们目前只需要设置索引位

    +

    由于在实验中不会使用到局部描述符表，因此在此处不会介绍它，这一位直接设置为0

    +

    同时特权级位会在后面涉及到用户进程时再次介绍，目前我们只需要关心RPL = 0的段

    +
    +

    总的来说，操作系统内的代码首先在内存中的全局描述符表内声明需要用到的段，之后将对应段的选择子提供给CPU，CPU在产生地址后，根据选择子中的信息在全局描述符表中查询段的具体信息来判断访问是否越界

    +

    进入保护模式

    +

    在了解了保护模式以及全局描述符表的相关知识后，就可以编写代码在BootLoader中开启保护模式了

    +

    进入保护模式
    +进入保护模式有五个步骤，分别是 设置全局描述符表、关闭中断， 开启第21根地址线、打开保护模式开关 和 执行一次远跳转送入代码段选择子

    +
    +

    首先进行第一步：设置全局描述符表

    +

    通过上一小节可以知道，全局描述符表实际上就是存放在内存中的一段类似于数组的空间，但是目前我们还没有指定这一段空间的位置，所以要先进行内存规划

    +

    实际上位置的指定相对自由，在实验中将GDT放置在0x9000-0x10000的位置处

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    用途起始地址终止地址扇区数
    MBR0x7C000x7E001
    BootLoader0x7E000x86004
    GDT0x90000x10000-
    +

    将新的常数写入头文件中方便调用

    +
    1
    2
    ; BootLoader
    GDT_START_ADDRESS equ 0x9000
    +

    之后，在BootLoader中向GDT中添加元素，在实验中我们使用平坦模式，所以只需要添加代码段、数据段以及栈段的描述符，以及最初的空描述符

    +

    平坦模式
    +平坦模式就是所有的段都对所有地址空间有完整的访问权限，并且所有的程序使用同一个代码段，简化了地址的访问
    +之所以使用这个模式是因为在后面的实验中，会有另一套地址管理的机制，称为分页机制，地址的保护将会使用分页机制进行

    +
    +

    可以根据段特性来设置描述符的值

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    段起始地址段界限ARWDCESDPLPLDBG描述符值
    空0x00x000000000000x00000000_00000000
    代码0x00xFFFFFFFF01011010110x00CF9A00_0000FFFF
    数据0x00xFFFFFFFF01001010110x00CF9200_0000FFFF
    栈0x00x001101010110x00CF9600_0000FFFF
    +

    确定了描述符值以后，使用mov命令放置在给GDT分配的内存空间中

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    ; Initialize Global Descriptor Table
    ; 0x0 Empty selector
    mov dword [GDT_START_ADDRESS + 0 * 4], 0x00000000
    mov dword [GDT_START_ADDRESS + 1 * 4], 0x00000000

    ; 0x08 Kernel code selector
    mov dword [GDT_START_ADDRESS + 2 * 4], 0x0000FFFF
    mov dword [GDT_START_ADDRESS + 3 * 4], 0x00CF9A00

    ; 0x10 Kernel data selector
    mov dword [GDT_START_ADDRESS + 4 * 4], 0x0000FFFF
    mov dword [GDT_START_ADDRESS + 5 * 4], 0x00CF9200

    ; 0x18 Kernel stack selector
    mov dword [GDT_START_ADDRESS + 6 * 4], 0x0000FFFF
    mov dword [GDT_START_ADDRESS + 7 * 4], 0x00CF9600
    +

    陷阱：注意小端模式
    +在IA-32处理器中，数据的存储使用的是小端模式
    +这就意味着对于一个64位的数据，低地址存放低32位，高地址存放高32位
    +虽然对于低32位，其存放顺序同样是小端模式，但是具体怎么放是mov指令的事情，我们就不需要关心了，我们只需要知道在使用mov指令的时候，宏观上要把低32位放在低地址上就对了

    +
    +

    根据写入的顺序就可以设置描述符对应的选择子了，由于我们只使用GDT而且只考虑特权级为0的情况，因此选择子的低3位均为0

    +

    将选择子以及描述符个数写入头文件中方便重用

    +
    1
    2
    3
    4
    5
    ZERO_SELECTOR equ 0x00
    KERNEL_CODE_SELECTOR equ 0x08
    KERNEL_DATA_SELECTOR equ 0x10
    KERNEL_STACK_SELECTOR equ 0x18
    GDT_SIZE equ 4
    +

    设置好了GDT里的内容后，就要考虑如何将其装载入GDTR了

    +

    由于GDTR为糟糕的48位长度，很显然没有一个寄存器能够放下这样长度的数据，因此工程师们又想出了一个天秀的方式：先把要放入GDTR的值放置在内存的一段地址中，然后使用lgdt命令读取这个地址，由该指令将地址之后的48位数据拷贝到GDTR中

    +

    所以首先指定一段用于存放GDTR数据的内存

    +
    1
    2
    3
    ; Variables
    gdt_descriptor  dw 0,
                    dd GDT_START_ADDRESS
    +

    陷阱：注意小端模式
    +在汇编的变量声明中，先声明的数据位于低地址
    +由于IA-32处理器又是小端模式，所以GDTR中的Size段位于低地址，应该先声明，然后再声明其Base段

    +
    +

    在BootLoader中由 Size=Count×8−1Size = Count \times 8 - 1 这一公式来设置GDT的大小

    +
    1
    2
    ; Set table size
    mov word [gdt_descriptor], GDT_SIZE * 8 - 1
    +

    一切准备妥当后，就是用lgdt指令将这糟糕的48位长度数据送入寄存器

    +
    1
    2
    ; Load gdt
    lgdt [gdt_descriptor]
    +

    然后进行关中断操作

    +

    之所以要关中断，是因为在保护模式下中断的实现与实模式下不一样，在我们尚未实现中断的时候，贸然进入保护模式会产生错误。因此我们先在BootLoader中关闭中断，当我们在后续章节中建立起完善的中断机制之后再打开中断

    +
    1
    cli   ; Disable interrupt
    +

    在关闭中断后，就可以进行第三步：开启第21根地址线

    +

    在实模式下，CPU始终将21根地址线置为低电平，这样不论指令寄存器如何自增，始终会因为溢出而在0xFFFFF处回到0x00000
    +为了进入保护模式，就需要解除这一层封印，让寻址突破20位限制

    +

    在编写BootLoader中的代码前，可以先看一段有趣的代码来感受CPU是如何通过第21根地址线将地址限制在20位的

    +
    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
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    ; The following code is public domain licensed
     
    [bits 16]
     
    ; Function: check_a20
    ;
    ; Purpose: to check the status of the a20 line in a completely self-contained state-preserving way.
    ;          The function can be modified as necessary by removing push's at the beginning and their
    ;          respective pop's at the end if complete self-containment is not required.
    ;
    ; Returns: 0 in ax if the a20 line is disabled (memory wraps around)
    ;          1 in ax if the a20 line is enabled (memory does not wrap around)
     
    check_a20:
        pushf
        push ds
        push es
        push di
        push si
     
        cli                   ; Disable interrupt
     
        ; Save state----------
        xor ax, ax ; ax = 0
        mov es, ax
     
        not ax ; ax = 0xFFFF
        mov ds, ax
     
        mov di, 0x0500
        mov si, 0x0510
     
        mov al, byte [es:di]
        push ax
     
        mov al, byte [ds:si]
        push ax
        ; End save state-------

        ; Main code------------
        mov byte [es:di], 0x00
        mov byte [ds:si], 0xFF  ; If trunc, the addr should be (0xFFFF0 + 0x510) & 0xFFFFF = 0x500 otherwise should be 0x100500
     
        cmp byte [es:di], 0xFF
        ; End main code--------

        ; Restore state--------
        pop ax
        mov byte [ds:si], al
     
        pop ax
        mov byte [es:di], al
     
        mov ax, 0
        je check_a20__exit
     
        mov ax, 1
     
    check_a20__exit:
        pop si
        pop di
        pop es
        pop ds
        popf
     
        ret
    +

    至于打开这根地址线，由于该地址线由南桥A20端口控制，端口号为0x92，控制位位于第二位，因此代码编写如下

    +
    1
    2
    3
    4
    ; Open A20
    in  al, 0x92
    or  al, 0b0000_0010 ; Set A20 enabled
    out 0x92, al
    +

    接下来就来到了保护模式真正的开关，CR0寄存器中的PE位

    +
    1
    2
    3
    4
    ; Set PE
    mov eax, cr0
    or  eax, 1
    mov cr0, eax
    +

    最后执行一次远跳转，送入代码段选择子，正式开启保护模式，其中protected_mode_begin部分将在下一小节中完成

    +
    1
    jmp dword KERNEL_CODE_SELECTOR:protected_mode_begin
    +

    远跳转
    +远跳转由两个部分组成：段选择子和段内偏移，执行远跳转会将段选择子送入代码段寄存器CS，同时将段内偏移送入EIP，使得CPU在新的代码段的基地址上以新的段内偏移开始执行指令
    +由于代码段选择子 不能够手动设置，因此只能够通过远跳转进行设置，所以此处执行的远跳转主要目的是为了送入代码段选择子

    +
    +

    第二个Hello World

    +

    进入保护模式以后，自然要输出些什么才能确认前面的代码都正确无误地执行了。因此，在这一小节中就来实现保护模式中的第二个Hello World!

    +

    由于进入保护模式以后，代码全面进入了32位模式，所以也要添加对应的伪代码

    +
    1
    2
    3
    4
    5
    6
    7
    ; Protected mode starts here

    [bits 32] ; Indicates codes below run in 32-bit mode

    protected_mode_begin:

    ; Fill something later
    +

    这时，我们还没有设置好各个段选择子，因此应当尽快将数据段和栈段的选择子送入寄存器，由于暂时用不到附加的段寄存器，所以不妨将它们设置为空描述符

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    ; Set selectors
    mov ax, KERNEL_DATA_SELECTOR
    mov ds, ax
    mov ax, KERNEL_STACK_SELECTOR
    mov ss, ax
    mov ax, ZERO_SELECTOR
    mov es, ax
    mov fs, ax
    mov gs, ax
    +

    接着就可以移植原先实模式下的代码，鉴于实模式与保护模式地区别，在移植时需要进行如下修改

    + +

    陷阱：不是在32位模式下所有的寄存器都要使用32位
    +寄存器位宽的使用始终要符合数据的宽度，例如从内存取出字节的时候就应该使用寄存器的8位模式作为操作数，而不能一味地使用32位寄存器

    +
    +

    移植后的代码如下

    +
    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
    ; Print something
    xor eax, eax
    mov ebx, 0xB8000
    mov esi, 0
    print:
        mov dl, byte [_msg + esi]
        cmp dl, 0
        je  print_exit
        inc esi
        ; Calculate cordinate in vga memory
        mov eax, dword [_row]
        imul eax, 80
        add eax, dword [_col]
        imul eax, 2
        ; Copy character to memory
        mov edi, eax
        mov byte [ebx + edi], dl    ; Character to be printed
        mov byte [ebx + edi + 1], 0x0F  ; Black background with white foreground
        ; Set new cordinate
        add dword [_col], 1
        mov eax, dword [_col]
        cmp eax, 80
        jne add_row_exit
        add dword [_row], 1
        mov dword [_col], 0
        add_row_exit:
        ; Reture to top
        jmp print
    print_exit:

    ; Halt here
    jmp $

    ; Variables
    _row    dd 0
    _col    dd 0
    _msg    db 'Hello World!',
            db 0
    +

    完整的bootloader.asm如下

    +
    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
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    %include "boot.inc"
    [org 0x7E00]
    [bits 16]

    ; Disable interrupts
    cli

    ; Initialize Global Descriptor Table
    ; 0x0 Empty selector
    mov dword [GDT_START_ADDRESS + 0 * 4], 0x00000000
    mov dword [GDT_START_ADDRESS + 1 * 4], 0x00000000

    ; 0x08 Kernel code selector
    mov dword [GDT_START_ADDRESS + 2 * 4], 0x0000FFFF
    mov dword [GDT_START_ADDRESS + 3 * 4], 0x00CF9A00

    ; 0x10 Kernel data selector
    mov dword [GDT_START_ADDRESS + 4 * 4], 0x0000FFFF
    mov dword [GDT_START_ADDRESS + 5 * 4], 0x00CF9200

    ; 0x18 Kernel stack selector
    mov dword [GDT_START_ADDRESS + 6 * 4], 0x0000FFFF
    mov dword [GDT_START_ADDRESS + 7 * 4], 0x00CF9600

    ; Set table size
    mov word [gdt_descriptor], GDT_SIZE * 8 - 1

    ; Load gdt
    lgdt [gdt_descriptor]

    ; Open A20
    in  al, 0x92
    or  al, 0b0000_0010
    out 0x92, al

    ; Set PE
    mov eax, cr0
    or  eax, 1
    mov cr0, eax

    jmp dword KERNEL_CODE_SELECTOR:protected_mode_begin

    ; Halt here
    jmp $

    ; Variables
    gdt_descriptor  dw 0,
                    dd GDT_START_ADDRESS

    [bits 32]

    protected_mode_begin:

    ; Set selectors
    mov ax, KERNEL_DATA_SELECTOR
    mov ds, ax
    mov ax, KERNEL_STACK_SELECTOR
    mov ss, ax
    mov ax, ZERO_SELECTOR
    mov es, ax
    mov fs, ax
    mov gs, ax

    ; Print something
    xor eax, eax
    mov ebx, 0xB8000
    mov esi, 0
    print:
        mov dl, byte [_msg + esi]
        cmp dl, 0
        je  print_exit
        inc esi
        ; Calculate cordinate in vga memory
        mov eax, dword [_row]
        imul eax, 80
        add eax, dword [_col]
        imul eax, 2
        ; Copy character to memory
        mov edi, eax
        mov byte [ebx + edi], dl    ; Character to be printed
        mov byte [ebx + edi + 1], 0x0F  ; Black background with white foreground
        ; Set new cordinate
        add dword [_col], 1
        mov eax, dword [_col]
        cmp eax, 80
        jne add_row_exit
        add dword [_row], 1
        mov dword [_col], 0
        add_row_exit:
        ; Reture to top
        jmp print
    print_exit:

    ; Halt here
    jmp $

    ; Variables
    _row    dd 0
    _col    dd 0
    _msg    db 'Hello World!',
            db 0

    +

    完成
    +至此，就完成了本章的全部任务，赶紧使用make clean build run来测试代码的运行情况吧！

    +
    diff --git a/source/_posts/os-journal-vol-4.md b/source/_posts/os-journal-vol-4.md new file mode 100644 index 0000000..1f19592 --- /dev/null +++ b/source/_posts/os-journal-vol-4.md @@ -0,0 +1,1681 @@ +--- +title: 操统实验日志 第四章 勇者之路 +date: 2022-08-20 13:44:51 +description: 本章第一部分中，将会简要介绍在下一章中将要编写的 KernelLoader，以及在开始着手进行它的编写之前所需要完成的，包括各种驱动、文件系统接口等在内的诸多准备工作。在第一部分之后，我决定按照 KernelLoader 中的函数调用顺序，逐节完成 KernelLoader 中所需要的所有准备工作，例如如何在项目中使用C语言和汇编混合编程，包括C语言是如何进行函数调用的，以及内联汇编中NASM向AT&T迁移语法所需要注意的问题、根据文档完成FAT文件系统接口的设计和实现等。 +tags: + - 操作系统 + - 大学 +categories: + - 技术 +--- + +

    关于本章

    +

    在本章节的第一部分中，将会简要介绍在下一章中将要编写的KernelLoader，以及在开始着手进行它的编写之前所需要完成的，包括各种驱动、文件系统接口等在内的诸多准备工作。

    +

    在第一部分之后，我决定按照KernelLoader中的函数调用顺序，逐节完成KernelLoader中所需要的所有准备工作，因此在第二部分中，将会首先记录如何在项目中使用C语言和汇编混合编程，包括C语言是如何进行函数调用的，以及内联汇编中NASM向AT&T迁移语法所需要注意的问题。有了这部分基础知识，就可以进行第三部分编写一些常用的驱动，并从我个人的角度讲讲为什么要这么做，它对后续的代码编写能够起到哪些帮助。

    +

    在之后的第四部分中，会进行有关文件系统的知识的详述，并且带领大家阅读微软关于FAT文件系统的文档，根据文档完成FAT文件系统接口的设计和实现。

    +

    而第五部分则会关注如何在多个分区的磁盘上通过MBR读取不同分区的信息，从而为正确读取文件系统中的文件提供条件

    +

    在第六部分中，会介绍我个人认为的操作系统中最重要的概念之一的分页机制，并根据我对它的理解，完成对分页机制中主要数据结构的抽象。

    +

    如果你恰好像我一样，在第二部分中阅读的是人生中第一篇官方的文档的话，应当能够克服曾经对于文档的恐惧，甚至会在阅读后面的小节时仍意犹未尽，激动不已，那么第七部分将会趁热打铁，跟随关于ELF文件的文档完成对ELF文件格式中用到的主要数据结构的抽象。

    +

    本章内容提示：
    +是的，这一章内容确乎是超乎我想象得多，这也就导致了学校官方教程中绕过了这一部分直接进入Kernel先着手编写Kernel中的内容
    +事实上，就实现 从BootLoader加载到Kernel 这一步骤，甚至KernelLoader都并不是必须的，但省略这一部分并不是没有代价的：由于省去了进入Kernel前的分页机制准备工作，学校教程不得不在第八次实验中返回BootLoader，添加开启分页的代码
    +除此之外，在我们要实现的ElfLoader的加持下，Kernel不再需要以.bin的形式编译，也不再需要单独的entry.asm文件作为入口，并且可以加载到任意指定的地址处

    +
    +

    最后一个跳板：KernelLoader

    +

    在上一章中，已经成功地从MBR跳转进入了BootLoader并且在BootLoader中开启了保护模式。

    +

    在成功开启了保护模式之后，其实就已经可以进入内核运行了。事实上，学校的教程也确乎是这么实现的：就如同MBR跳转BootLoader那样，将内核编译为.bin文件并从BootLoader加载后跳转到内核加载地址上运行。

    +

    而我的实现则相较于学校教程而言复杂了许多，在我的实现中，BootLoader与Kernel间额外添加了一层跳板，也就是在下一章中要完成的KernelLoader，它负责从硬盘活动分区的/system/文件夹中读取kernel.elf文件，并且解析kernel.elf文件中的信息，将内核加载到正确的地址，之后开启分页机制，最后跳转到Kernel运行。

    +

    看上去，学校教程的实现方式更加简单，但这样的捷径并非没有代价，至于学校教程有哪些弊端，以及为什么我采用了一条这样的路线，在后续小节和章节的实现中，都会渐渐明朗。

    +

    为了完成这样一个复杂的跳板程序，需要为其做许多的前期准备工作：

    + +

    这也就意味着我们的项目目录也会产生一些变化：

    + +

    在准备妥当后，新的项目结构如下

    +
    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
    .
    ├── build
    ├── run
    └── src
        ├── boot
        │   ├── bootloader.asm
        │   ├── boot.inc
        │   ├── klentry.asm
        │   └── mbr.asm
        ├── driver
        │   ├── harddisk
        │   └── port
        ├── kernel
        └── lib
            ├── common
            │   ├── constants.h
            │   └── types.h
            ├── mem
            │   ├── memory.cpp
            │   └── memory.h
            ├── str
            │   ├── str.cpp
            │   └── str.h
            └── struct
                ├── elf
                ├── fs
                ├── mbr
                └── paging
    +

    现在，就让我们开始接下来激动人心的旅程吧！

    +

    熟悉的朋友：C++闪亮登场

    +

    大家不会觉得KernelLoader要使用汇编完成吧，不会吧不会吧

    +

    离开了实模式进入32位保护模式后，C++就已经可以大展身手了，也就是说，从接下来开始就将脱离汇编苦海，投入C++的怀抱之中了。

    +

    不过，在正式开始C++的工作前，需要完成一些交接的工作，在这一小节中，将会介绍一个C++程序是如何从源文件编程可执行文件的，以及如何进行C++与汇编的混合编程

    +

    从代码到可执行文件

    +

    参考：
    +本节内容参考了学校教程第四次实验中从代码到可执行文件一章以及C/C++和汇编混合编程一章的内容

    +
    +

    在编译器将代码编译成可执行文件的过程中，其实际上进行了四个步骤：预处理、编译、汇编和链接

    +

    预处理又称为预编译，在这一环节中，编译器主要处理宏定义，如#include, #define, #ifndef等，并删除注释行，还会添加行号和文件名标识，在编译时编译器会使用上述信息产生调试、警告和编译错误时需要用到的行号信息。
    +经过预编译生成的.i文件不包含任何宏定义，因为所有的宏已经被展开，并且包含的文件也已经被插入到.i文件中

    +

    我们可以通过新建一个简单的C程序main.cpp来测试这一步骤：

    +
    1
    2
    3
    4
    5
    6
    #include <stdio.h>

    int main() {
        printf("Hello world!\n");
        return 0
    }
    +

    之后在编译命令中使用-E参数只进行预编译步骤

    +
    1
    gcc -o main.i -E main.cpp
    +

    查看Linux关于指令的手册：
    +如果想要知道关于某一程序参数的具体描述，可以使用man命令
    +例如，man gcc可以查看关于gcc所有参数的描述和用法，其中关于-E参数就有如下描述：
    +-E Stop after the preprocessing stage; do not run the compiler proper. The output is in the form of preprocessed source code, which is sent to the standard output.

    +
    +

    可以看到生成了一个main.i文件，其内容如下：

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    # 1 "main.cpp"
    # 1 "<built-in>"
    # 1 "<command-line>"
    # 1 "/usr/include/stdc-predef.h" 1 3 4
    # 1 "<command-line>" 2
    # 1 "main.cpp"
    ...
    # 10 "main.cpp"
    int main() {
        printf("Hello world!\n");
        return 0;
    }
    +

    编译是将预处理后的代码翻译成汇编语法的步骤，具体包括了词法分析、语法分析、语义分析及相关的优化、中间代码生成以及目标代码生成五个环节

    +

    在gcc中使用-S参数可以进行编译步骤，-masm=intel指定输出的语法格式为第二章中介绍的Intel汇编语法

    +
    1
    gcc -o main.s -S main.cpp -masm=intel
    +

    生成的main.s文件如下：

    +
    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
      .file "main.cpp"
      .text
      .section  .rodata
    .LC0:
      .string "Hello world!"
      .text
      .globl  main
      .type main, @function
    main:
    .LFB0:
      .cfi_startproc
      endbr64
      pushq %rbp
      .cfi_def_cfa_offset 16
      .cfi_offset 6, -16
      movq  %rsp, %rbp
      .cfi_def_cfa_register 6
      leaq  .LC0(%rip), %rdi
      call  puts@PLT
      movl  $0, %eax
      popq  %rbp
      .cfi_def_cfa 7, 8
      ret
      .cfi_endproc
    .LFE0:
      .size main, .-main
      .ident  "GCC: (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0"
      .section  .note.GNU-stack,"",@progbits
      .section  .note.gnu.property,"a"
      .align 8
      .long  1f - 0f
      .long  4f - 1f
      .long  5
    0:
      .string  "GNU"
    1:
      .align 8
      .long  0xc0000002
      .long  3f - 2f
    2:
      .long  0x3
    3:
      .align 8
    4:
    +

    在汇编步骤中，编译生成的汇编代码将会被翻译成机器语言，并且组织成为可重定位文件的格式。在Linux下，可重定位文件是ELF格式，关于ELF格式的文档中详细地介绍了ELF格式中的各个部分，以及它们如何对重定位起作用。

    +

    ELF文件有多种类别：
    +ELF不仅可以用来描述需要重定位的文件，也可以用在链接环节的生成的可执行文件中，在本文的第六部分中，就要根据文档来介绍如何解析一个可执行的ELF格式文件

    +
    +

    汇编步骤仅仅只是将单个的文件转换成了机器语言，如果项目中有许多文件，它们中又存在着调用关系的话，此时是没有办法执行的。可以这么理解：在编译器进行汇编的时候，它会遇到一些只有声明而没有定义的符号，例如一些外部函数和变量，这部分函数和变量的地址此时还并不知道，因此编译就会将它们标记起来，放置在ELF文件一些特殊的区域存储

    +

    在链接步骤中，链接器接受多个输入的可重定位文件，根据输入的参数设置，可以规定程序的入口点地址、程序代码段放置的地址等，然后按照设置的地址将文件中的各个部分组合拼接在一起。

    +

    由于在链接的步骤中，程序起始的地址通过参数规定，同时所有的文件此时都“齐聚一堂”，每个文件各个代码段就可以像安排座位那样依次入座了，整个程序各个符号的绝对地址也就确定了。这样，原先那些没有定义的符号此刻也能够找到了，并且也具有了绝对的地址值，各个文件中的相对地址此刻也都有了对应的绝对地址值，链接器根据这些新确定的绝对地址替换掉类似jmp、call中原先使用的值，将整个程序完整地串联在一起。

    +

    类似jmp这样的跳转指令，就是在链接的步骤中，才真正确定跳转的绝对地址的。

    +
    +

    C++与汇编混编

    +

    即便有了C++这一利器，在实验中的许多地方仍然不可避免会需要用到汇编语言，例如需要操作某个特殊寄存器或是需要读写端口的时候。在这种情况下，有两种可行的解决方案，分别是 内联汇编 和 调用汇编函数

    +

    学校所提供的教程在第四次实验的C/C++和汇编混合编程这一部分介绍了调用汇编函数这一解决方案

    +

    在这个解决方案中，主要需要三个步骤：

    +
      +
    1. 将需要通过汇编实现的功能通过汇编函数的形式写在.asm文件中，并声明global
      2. +
    2. 在需要调用函数的C程序头文件中提供extern "C" boo baz()这样的外部函数声明，并在程序中调用这个函数来执行对应的功能
      3. +
    3. 在链接步骤中将汇编和C程序一同链接
      4. +
    +

    此外，为了能够让汇编函数的编写和调用能够顺利进行，还需要了解编译器是如何处理带参函数的调用的，我们不妨写一个带有参数的函数来试一试

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    void func(int a, char b) {
        //Do nothing here
        return;
    }

    int main() {
        func(1, 'A');
        return 0;
    }
    +

    之后使用编译器编译成汇编代码，其中main函数对应调用func部分的代码如下

    +
    1
    2
    3
    4
    push  65
    push  1
    call  _Z4funcic
    add esp, 8
    +

    可以看出，两个push操作分别向栈内压入了'A'和1两个参数，之后使用call指令调用函数，在函数返回后再使用add esp, 8将参数移出栈，

    +

    图 1

    +

    进入函数内也不能干坐着，按照C语言的规定，被调函数需要使用ebp从栈上取值，同时还需要为主调函数保留ebp寄存器的值，因此可以看到在汇编被调函数内部有这样的代码

    +
    1
    2
    3
    4
    5
    6
    7
    push ebp      //Preserve ebp
    mov ebp, esp  //Move esp to ebp

    //Function body

    pop ebp       //Restore ebp
    ret           //Return
    +

    当然，尽管C语言似乎并没有要求被调函数主动保存其他寄存器的值，但我个人而言还是习惯在进入函数之后进行一次pushad操作主动保存，这也就让固定的函数骨架变为了

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    push ebp
    mov ebp, esp
    pushad

    //Function body

    popad
    pop ebp
    ret
    +

    关于调用汇编函数的实例：
    +如果想要查看关于上述方案的实例，可以参考学校教程的第四次实验 Example 1 混合编程 相关内容

    +
    +

    上述方法为了调用一个汇编函数还要额外添加一个.asm文件，实在是不够优雅，所以我在后续的实现中改为了使用内联汇编来完成汇编代码的部分

    +

    实际上，内联汇编的使用极其简单（对于实验中所需要用到的部分而言），由于主要需要和内联汇编打交道的地方几乎无外乎都是要么从寄存器读出一个值，要么往寄存器写入一个值，所以并不需要学习多么复杂的语法，够用即可

    +

    在GCC中使用内联汇编，只需要使用asm关键字，如果不希望编译器改动汇编代码顺序，可以额外添加volatile关键字，于是，一个最简单的内联汇编语句可以长这样：

    +
    1
    2
    3
    asm volatile(
      "nop"
    );
    +

    如果代码有很多行的话，就长这样：

    +
    1
    2
    3
    4
    5
    asm volatile(
      "nop\n\t"
      "nop\n\t"
      "nop"
    );
    +

    是否已经跃跃欲试了？且慢，内联汇编默认使用的是AT&T的语法，因此我们需要进行一次Intel语法向AT&T语法的迁移，在了解了Intel与AT&T语法的主要区别之后，我们不论是写.asm文件还是写内联汇编都将得心应手

    +

    参考资料：
    +关于语法迁移的内容，参考了 GCC 内联汇编与 Intel 语法迁移 一文

    +
    +

    Intel和AT&T的语法区别，无外乎以下几点：

    + +

    最后，为了能够让内联汇编功能更强大，GCC还提供了一系列扩展的指令操作：

    +
    1
    2
    3
    4
    5
    6
    asm volatile(
      "nop"
      : //Output
      : //Input
      : //Registers
    )
    +

    可以看到，在正常指令的尾部，GCC允许程序员添加三个参数列表，类似于printf函数那样，通过在汇编代码中插入特定的操作数，并在后面的参数列表中按照规定的格式提供变量，可以使用变量来 “替换” 代码中对应的操作数，从而起到将变量值写入寄存器或是将寄存器值写入变量的操作。

    +

    其中，参数列表中每一个参数都由一个可选的名称[name]，一个限制符如"=r"、"i"等以及对应的变量(var)组成。

    +

    限制符在实验中只需要用到"r"以及"i"，其中

    + +

    除此之外，还有更多的限制符，如

    + +

    在汇编指令中，可以用%0、%1…%n这样从零开始的数字来表示参数列表中的第一个、第二个、…第n个变量，例如

    +
    1
    2
    3
    4
    5
    6
    7
    8
    int out_eax, in_eax = 10;

    asm volatile(
      "movl %%eax, %0\n\t"
      "movl %1, %%eax"
      : "=r"(out_eax)   //%0
      : "r"(in_eax)     //%1
    );
    +

    也可以使用%[name]的方式通过名称来直接对应参数列表中指定名字的变量，例如：

    +
    1
    2
    3
    4
    5
    6
    7
    8
    int out_eax, in_eax = 10;

    asm volatile(
      "movl %%eax, %[out]\n\t"
      "movl %[in], %%eax"
      : [out]"=r"(out_eax)
      : [in]"r"(in_eax)
    );
    +

    陷阱：额外的%
    +当使用了扩展内联汇编之后，由于诸如%0这样的操作数会使用一个%符号，为了区分，所有的语句中的寄存器都需要额外加一个%，例如movl %0, %%eax

    +
    +

    陷阱：变量大小与指令操作数大小对应
    +例如，如果使用了movl指令，那么对应的参数列表中的变量也应当是32位长度，例如int

    +
    +

    至此，内联汇编的优势已然显现出来，其不但减少了杂乱文件的数目，而且还可以方便的与C程序中的变量进行操作，在后续的实验中选择哪种方案相比心里也有了答案。

    +

    但不论选择哪一个方案完成C和汇编的混合编程，至此我们都已经顺利完成了进入C++语言环境的全部知识准备，足够我们进入后面的小节继续实验的进程了。

    +

    驱动：抽象硬件交互

    +

    在操作系统实现的各个环节中，都离不开和硬件打交道的部分，在我们已经完成的MBR中，就有我们为了加载BootLoader而写的读取磁盘扇区的函数。

    +

    这些需要和硬件进行通信的操作，往往都需要用到一些特殊的端口，通过我们实现MBR的经历可以知道，使用汇编的in和out指令就可以对端口进行读写操作，而这样简单的操作如果是使用C++这样的语言进行编程的话却是无法实现的。

    +

    这时，大家可能就会说了，不是刚刚学完了C++和汇编混编吗，这不直接上来就是一个asm ("inb dx, al")，很快啊！

    +

    不可否认，这不失为一个解决方式，但放在C++中，它就是显得不那么优雅：如果能把一个端口视为一个对象，比如port，直接port.read()，这才叫优雅嘛！

    +

    可喜的是，这在C++中是完全可以实现的：只需要实现一个类，其持有一个端口号作为成员变量，读写操作的实现则都使用内联汇编完成。

    +

    这样就相当于在汇编操作外附加了一层C++的外衣，将原先裸的内联汇编代码包装成了C++代码，不仅提升了代码的可读性，而且由于存在C++的类作为中间层，可以添加很多保护性的代码，比如判断非法端口的访问、只读端口的写入等等，相比直接操作裸汇编代码提升了安全性和灵活性。

    +

    端口驱动

    +

    在实现端口驱动的时候，可以根据端口的读写权限分为三个类：

    + +

    对于Port类，由于汇编中的in和out指令都需要提供端口号，而既然我们现在打算将一个端口封装成一个Port的实例，那就不能每次调用读写函数的时候都提供一次端口号，而是要让实例在初始化的时候就记住它应当是哪个端口。由于这个端口号只有在初始化的时候被赋值，之后就不再需要更改或是暴露给程序，因此可以作为私有的const变量进行储存：

    +
    1
    2
    private:
        const uint16 _port;
    +

    对于端口的读写函数，由于不同的端口位宽会存在不同，因此读写指令的返回值和参数的类型需要借助类模板的帮助：

    +
    1
    2
    3
    4
    5
    6
    template<typename T>
    class Port {
        public:
            T read() const;
            void write(T data) const;
    }
    +

    又因为在内联汇编中，in和out指令都需要指定操作数的宽度，如inb或是inl，因此在读写函数的实现上，要使用sizeof(T)对模板类的类型参数位宽进行判断，再使用合适的内联汇编函数，例如：

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    template<typename T>
    T Port<T>::read() const {
        //...
        if(sizeof(dat) == 1) {
            //8-bit port
        }
        else if(sizeof(dat) == 2) {
            //16-bit port
        }
        else {
            //32-bit port
        }
        //...
    }
    +

    对于一个8位端口，使用内联汇编的读取代码可以首先将端口号读取到dx，再使用inb指令读取端口数据到al，最后将数据从al写入到外部变量：

    +
    1
    2
    3
    4
    5
    6
    7
    8
    asm volatile(
        "movw %[p], %%dx \n\t"
        "inb  %%dx, %%al \n\t"
        "movb %%al, %[o] \n\t"
        : [o] "=r"(_dat)
        : [p] "r"(_port)
        :
    );
    +

    内联汇编在编译的时候会检查外部变量的大小是不是和对应指令中指定的操作数宽度相匹配，例如movw指令不能提供一个uint16类型的变量，因此如果直接将T data作为参数传入，会发生报错。对于这个问题，可以在使用sizeof()判断后，显示地将data转换为对应的大小，或是先赋值到一个明确宽度的变量（例如：uint8 _data）中，再在C++中赋值给原先的变量：

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    template<typename T>
    T Port<T>::read() const {
        T dat;
        if(sizeof(dat) == 1) {
            uint8 _dat = static_cast<uint8>(dat);
            asm volatile(
                "movw %[p], %%dx \n\t"
                "inb  %%dx, %%al \n\t"
                "movb %%al, %[o] \n\t"
                : [o] "=r"(_dat)        //: [o] "=r"(dat) will cause compile time error
                : [p] "r"(_port)
                :
            );
            dat = _dat;
        }
        //...
        return dat;
    }
    +

    由于只写或是只读的端口在读、写函数的实现上与可读写端口中的读写函数没有任何区别，因此在我最初的实现中将Port类作为基类而PortWriteOnly和PortReadOnly私有继承Port，之后封装父类中对应的函数为类的公有接口，例如：在Port中的public: void _write(T data)函数在私有继承后，在PortWriteOnly中添加public: void write(T data) { _write(data); }来调用基类中的写接口，而不对读接口进行封装，来实现读写权限的限制。

    +

    但在后续的实验中我发现，即便父类中的函数由于继承已经实质是类的私有函数，但在Intellisense中仍然可以看到，感觉还是不够安全。因此我决定不继承的方式，转而对于PortWriteOnly存储一个Port类型的成员变量代替Port中的端口号，在写函数中调用Port::write函数，彻底杜绝在PortWriteOnly中出现read函数的提示。

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    template<typename T>
    class PortWriteOnly {
        public:
            PortWriteOnly(uint16 port) : _port(port) {}
        private:
            const Port<T> _port;
        public:
            void write(T data) const { 
                _port.write(data);
            }
    };
    +

    完整的端口驱动ports.h如下：

    +
    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
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    #include "types.h"

    #ifndef _PORT_H_
    #define _PORT_H_

    template<typename T>
    class Port {
        public:
            Port(uint16 port): _port(port) {}
        private:
            const uint16 _port;
        public:
            T read() const;
            void write(T data) const;
    };

    template<typename T>
    class PortWriteOnly {
        public:
            PortWriteOnly(uint16 port) : _port(port) {}
        private:
            const Port<T> _port;
        public:
            void write(T data) const { 
                _port.write(data);
            }
    };

    template<typename T>
    class PortReadOnly {
        public:
            PortReadOnly(uint16 port) : _port(port) {}
        private:
            const Port<T> _port;
        public:
            T read() const {
                return _port.read();
            }
    };

    template<typename T>
    T Port<T>::read() const {
        T dat;
        if(sizeof(dat) == 1) {
            uint8 _dat = static_cast<uint8>(dat);
            asm volatile(
                "movw %[p], %%dx \n\t"
                "inb  %%dx, %%al \n\t"
                "movb %%al, %[o] \n\t"
                : [o] "=r"(_dat)
                : [p] "r"(_port)
                :
            );
            dat = _dat;
        }
        else if(sizeof(dat) == 2) {
            uint16 _dat = static_cast<uint16>(dat);
            asm volatile(
                "movw %[p], %%dx \n\t"
                "inw  %%dx, %%ax \n\t"
                "movw %%ax, %[o] \n\t"
                : [o] "=r"(_dat)
                : [p] "r"(_port)
                :
            );
            dat = _dat;
        }
        else {
            uint32 _dat = static_cast<uint32>(dat);
            asm volatile(
                "movw %[p], %%dx \n\t"
                "inl  %%dx, %%eax \n\t"
                "movl %%eax, %[o] \n\t"
                : [o] "=r"(_dat)
                : [p] "r"(_port)
                :
            );
            dat = _dat;
        }
        return dat;
    }

    template<typename T>
    void Port<T>::write(T data) const {
        if(sizeof(data) == 1) {
            asm volatile(
                "movb %[i], %%al \n\t"
                "movw %[p], %%dx \n\t"
                "outb %%al, %%dx \n\t"
                : 
                : [i] "r"(static_cast<uint8>(data)), [p] "r"(_port)
            );
        }
        else if(sizeof(data) == 2) {
            asm volatile(
                "movw %[i], %%ax \n\t"
                "movw %[p], %%dx \n\t"
                "outw %%ax, %%dx \n\t"
                : 
                : [i] "r"(static_cast<uint16>(data)), [p] "r"(_port)
            );
        }
        else {
            asm volatile(
                "movl %[i], %%eax \n\t"
                "movw %[p], %%dx \n\t"
                "outl %%eax, %%dx \n\t"
                : 
                : [i] "r"(static_cast<uint32>(data)), [p] "r"(_port)
            );
        }
    }

    #endif
    +

    陷阱：模板类的函数应在头文件中定义
    +模板类的函数不能将函数声明写在头文件中，而将函数的定义写在另一个文件中，这样会导致在编译链接的时候出现无法找到函数定义的报错。所有的模板类函数都需要在头文件中就实现函数的定义。

    +
    +

    硬盘驱动

    +

    回顾：从硬盘读取多个扇区的数据
    +关于如何使用LBA模式通过端口读写磁盘，可以回顾第三章中相关内容的介绍

    +
    +

    要将硬盘的读写操作抽象成驱动，在实验中使用了与第三章中相同的PIO模式对硬盘进行访问，在这个模式下与硬盘通信需要使用到8个不同的端口：

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    端口号端口数据传输方向作用 (LBA28)描述位长 (LBA28)
    0x1F0读/写数据寄存器硬盘读出/要写入的数据16-bit
    0x1F1读错误码寄存器存储执行的ATA指令所产生的错误码8-bit
    0x1F1写功能寄存器用来指定特定指令的接口功能8-bit
    0x1F2读/写扇区数寄存器存放需要读写的扇区数量8-bit
    0x1F3读/写起始扇区寄存器存放起始扇区0-7位8-bit
    0x1F4读/写起始扇区寄存器存放起始扇区8-15位8-bit
    0x1F5读/写起始扇区寄存器存放起始扇区16-23位8-bit
    0x1F6读/写磁盘、起始扇区寄存器选择磁盘和访问模式
    存放起始扇区24-27位    		8-bit
    0x1F7读状态寄存器读取当前磁盘状态8-bit
    0x1F7写指令寄存器传送ATA指令8-bit
    +

    既然前面已经实现了端口的驱动，那么在这里就可以直接投入使用了，将列表中的端口按照对应的读写权限和用途实例化作硬盘类HDDManager的私有成员变量：

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    private:
        const Port<uint16> _datPort = 0x1F0;
        const PortReadOnly<uint8> _errPort = 0x1F1;
        const PortWriteOnly<uint8> _funcPort = 0x1F1;
        const Port<uint8> _secCntPort = 0x1F2;
        const Port<uint8> _lbaLoPort = 0x1F3;
        const Port<uint8> _lbaMidPort = 0x1F4;
        const Port<uint8> _lbaHiPort = 0x1F5;
        const Port<uint8> _drivePort = 0x1F6;
        const PortReadOnly<uint8> _statusPort = 0x1F7;
        const PortWriteOnly<uint8> _cmdPort = 0x1F7;
    +

    注意到，对于0x1F7端口，当其作为读端口时用来表示硬盘的状态，其表示形式为按位枚举，端口读出值的每一位都有对应的含义：

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    端口号位缩写作用
    0x1F7 (Read)0ERR指示是否有错误发生，通过发送新指令可以清除该位
    0x1F7 (Read)1*IDX索引，始终置为0
    0x1F7 (Read)2*CORR修正数据，始终置位0
    0x1F7 (Read)3DRQ0：硬盘还不能交换数据
    1：硬盘存在可以读取的数据或是可以写入数据
    0x1F7 (Read)4*SRV重叠模式服务请求
    0x1F7 (Read)5*DF驱动器故障错误
    0x1F7 (Read)6*RDY0：驱动器发生了减速或是错误
    1：驱动器运转正常
    0x1F7 (Read)7BSY忙位
    0：空闲
    1：忙
    +

    什么是按位枚举：
    +按位枚举就是指利用二进制位来表示某个事物的属性，不同的二进制位描述不同的属性。
    +例如，对于一个人的特征来说，可以用202^0所在的位表示性别，1为男，0为女；用212^1所在的位表示是否是短发，1为是，0为否，等等。
    +需要注意的是，在使用按位枚举的时候，不同的二进制位应当描述不同的属性，例如如果要表示性别应当使用一个二进制位的0和1来区别，而不是使用两个二进制位，一个置位表示男，另一个置位则表示女。

    +
    +

    由上述的列表中可以看出0x1F7中的每个二进制位都确实描述了一个硬盘状态的不同属性，对于这样的二进制位枚举，可以通过enum来表示：

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    enum HDDStatus {
        ERR_OCCURRED            = 1,
        IDX                     = 1 << 1,
        CORR                    = 1 << 2,
        DATA_READY              = 1 << 3,
        OVERLAPP_SRVICE_REQUEST = 1 << 4,
        DRIVE_FAULT_ERR         = 1 << 5,
        DRIVE_READY             = 1 << 6,
        BUSY                    = 1 << 7
    };
    +

    但糟就糟在C++对按位枚举的支持并不好，由于C++默认将枚举类型作为整型值处理，所以常见的按位操作是默认支持的：

    + +

    但如果想重载一些特殊的运算，或是添加一些特殊的判断函数，枚举类型则显得无从下手了：

    + +

    为了支持这些操作，可以使用C++的类对原本的枚举类型进行一次封装：将枚举类型声明在C++类内，使用一个私有变量存储实际的枚举值，并通过重载运算符的方式从而让类的实例能够支持上述所有的运算操作。

    +

    对于目前而言，为硬盘的状态属性定义类HDDStatusFlag，并将原先的枚举类型声明在这个类内：

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    class HDDStatusFlag {
        public:
            enum ATTR {
                ERR_OCCURRED            = 1,
                IDX                     = 1 << 1,
                CORR                    = 1 << 2,
                DATA_READY              = 1 << 3,
                OVERLAPP_SRVICE_REQUEST = 1 << 4,
                DRIVE_FAULT_ERR         = 1 << 5,
                DRIVE_READY             = 1 << 6,
                BUSY                    = 1 << 7
            };
    }
    +

    这样，如果想访问枚举类型中的某个常量值，例如BUSY，可以使用HDDStatusFlag::BUSY或是HDDStatusFlag::ATTR:BUSY访问到。

    +

    由于0x1F7端口为8位端口，所以对于HDDStatusFlag这个枚举类，其实际需要存储的数据为byte类型，因此可以使用一个byte类型的变量作为其私有成员，用来存储实际的枚举值：

    +
    1
    2
    private:
        byte _attr;
    +

    为了能直接使用整型值给HDDStatusFlag类型的变量赋值，需要定义一个参数为byte类型的构造函数：

    +
    1
    2
    3
    4
    public:
        HDDStatusFlag(byte flags) {
            _attr = static_cast<byte>(flags);
        }
    +

    有了这样的一个构造函数，类的实例就可以使用如下的方式构造了：

    +
    1
    2
    3
    HDDStatusFlag flag = HDDStatusFlag::ERR_OCCURRED | HDDStatusFlag::BUSY;
    //or
    HDDStatusFlag flag = 0x81;
    +

    至于其他的按位操作、特殊运算和判断函数的实现此处就不再赘述，无外乎就是对运算符进行重载，然后再对实际的值进行对应的运算或判断即可。

    +

    在完成了硬盘硬盘状态类的设计后，就可以开始实现硬盘的读写函数了。以硬盘的读取为例，其分为两个主要的步骤：从硬盘读取以及写入内存中的缓冲区。

    +

    由于目前在KernelLoader中没有一个完善的内存管理机制，而进入内核之后内存将可以通过堆分配器分配空闲的内存供程序使用，两者在内存申请上会存在很大的区别。

    +

    如果让HDDManager自行管理其在读写时需要用到的缓冲区的话，就需要分别为KernelLoader环境和内核环境设计不同的缓冲区申请和释放的机制，相当麻烦。考虑到驱动的通用性，所以不妨让内存申请的步骤对HDDManager这个类完全不可见，由调用读写函数的调用者主动申请对应大小的内存，并将申请到的内存首地址作为参数传递给读写函数，所以读写函数的签名声明如下：

    +
    1
    2
    3
    public:
        bool readSector(uint idx, uint cnt, byte* dst);
        bool writeSector(uint idx, uint cnt, byte* src);
    +

    在读写函数的实现上，可以将多个扇区的读写拆分为多个单独扇区的读写，将单个扇区的读写函数作为私有成员仅供公有读写函数调用。

    +
    1
    2
    3
    private:
        bool _readOneSector(uint idx, byte* dst);
        bool _writeOneSector(uint idx, byte* src);
    +

    以读取的函数为例，单个扇区的读取步骤如下：

    +
      +
    1. 向_secCntPort端口写入读取的扇区数量0x01
      2. +
    2. 向_lbaLoPort端口写入读取的扇区号低8位
      3. +
    3. 向_lbaMidPort端口写入读取的扇区号8至15位
      4. +
    4. 向_lbaHiPort端口写入读取的扇区号高16至23位
      5. +
    5. 向_drivePort端口写入读取的扇区号高4位以及驱动的参数0xE0
      6. +
    6. 向_cmdPort端口写入读取命令0x20
      7. +
    7. 等待硬盘就绪，从_statusPort中读取硬盘的状态，如果状态包含了HDDStatusFlag::DATA_READY属性，则意味着硬盘数据准备完毕
      8. +
    8. 读取512字节到缓冲区中
      9. +
    +

    其中，如果在等待硬盘就绪的步骤中发生了错误，则会使用false返回值表示读取失败。

    +

    具体的实现如下：

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    bool HDDManager::_readOneSector(uint idx, byte* dst) {
        _secCntPort.write(0x01);    //Read 1 sector
        _lbaLoPort.write((uint8)idx);
        _lbaMidPort.write((uint8)(idx >> 8));
        _lbaHiPort.write((uint8)(idx >> 16));
        _drivePort.write(((uint8)(idx >> 24)) | 0xE0);
        _cmdPort.write(0x20);
        while(true) {
            HDDStatusFlag status = _statusPort.read();
            if(status.contains(HDDStatusFlag::ERR_OCCURRED)) {
                return false;
            }
            if(status.contains(HDDStatusFlag::DATA_READY)) {
                break;
            }
        }
        for(int i = 0; i < 512; i += 2) {
            uint16 tmpDat = _datPort.read();
            *(uint16*)(dst + i) = tmpDat;
        }
        return true;
    }
    +

    在读取多扇区的函数中，如果读取某个扇区时_readOneSector函数返回了false值，则会进而读取_errPort中的错误信息，写入缓冲区首2字节中，并返回false告知主调函数在硬盘读取过程中出现了错误。如果没有遇到错误，则继续下一个扇区的读取，然后向主调函数返回true。

    +

    具体的实现如下：

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    bool HDDManager::readSector(uint idx, uint cnt, byte* dst) {
        uint offset = 0;
        for(uint i = 0; i < cnt; i++) {
            if(!_readOneSector(idx + i, (byte*)(dst + offset))) {
                uint8 err = _errPort.read();
                memcpy(dst, &err, 8);
                return false;
            }
            offset += 512;
        }
        return true;
    }
    +

    对于硬盘写，操作则与硬盘读大同小异，仅仅是将数据的传输方向颠倒，从由_datPort读出数据变为向_datPort写入数据，从写入缓冲区变为从缓冲区取出数据而已，此处便不再赘述。

    +

    完整的hdd.h头文件如下：

    +
    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
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    #include "types.h"
    #include "memory.h"
    #include "ports.h"

    #ifndef _HDD_H_
    #define _HDD_H_

    class HDDStatusFlag {
        public:
            enum ATTR {
                ERR_OCCURRED            = 1,
                IDX                     = 1 << 1,
                CORR                    = 1 << 2,
                DATA_READY              = 1 << 3,
                OVERLAPP_SRVICE_REQUEST = 1 << 4,
                DRIVE_FAULT_ERR         = 1 << 5,
                DRIVE_READY             = 1 << 6,
                BUSY                    = 1 << 7
            };
            HDDStatusFlag() {}
            HDDStatusFlag(byte flags) {
                _attr = static_cast<byte>(flags);
            }
            HDDStatusFlag& operator=(byte flags) {
                _attr = static_cast<byte>(flags);
                return *this;
            }
            HDDStatusFlag& operator=(const HDDStatusFlag& other) {
                _attr = other._attr;
                return *this;
            }
            //Judge whether two flags are equal
            bool operator==(byte flags) {
                return _attr == static_cast<byte>(flags);
            }
            //Combine two flags
            HDDStatusFlag operator+(byte flags) {
                byte newAttr = _attr | static_cast<byte>(flags);
                return HDDStatusFlag(static_cast<byte>(newAttr));
            }
            HDDStatusFlag& operator+=(byte flags) {
                _attr |= static_cast<byte>(flags);
                return *this;
            }
            //Remove flags
            HDDStatusFlag operator-(byte flags) {
                byte newAttr = _attr & ~(static_cast<byte>(flags));
                return HDDStatusFlag(static_cast<byte>(newAttr));
            }
            HDDStatusFlag& operator-=(byte flags) {
                _attr &= ~(static_cast<byte>(flags));
                return *this;
            }
            //Bitwise or
            HDDStatusFlag operator|(byte flags) {
                byte newAttr = _attr | static_cast<byte>(flags);
                return HDDStatusFlag(static_cast<byte>(newAttr));
            }
            HDDStatusFlag& operator|=(byte flags) {
                _attr |= static_cast<byte>(flags);
                return *this;
            }
            //Bitwise and
            HDDStatusFlag operator&(byte flags) {
                byte newAttr = _attr & static_cast<byte>(flags);
                return HDDStatusFlag(static_cast<byte>(newAttr));
            }
            HDDStatusFlag& operator&=(byte flags) {
                _attr &= static_cast<byte>(flags);
                return *this;
            }
            //Reverse flags
            HDDStatusFlag operator~() {
                return HDDStatusFlag(static_cast<byte>(_attr));
            }
            //Toggle flag bits
            HDDStatusFlag& operator^=(byte flags) {
                _attr ^= static_cast<byte>(flags);
                return *this;
            }
            //Judge whether flags are contained
            bool contains(byte flags) {
                return (_attr & static_cast<byte>(flags)) == static_cast<byte>(flags);
            }
        private:
            byte _attr;
    };

    class HDDManager {
        public:
            HDDManager() {}
        private:
            const Port<uint16> _datPort = 0x1F0;
            const PortReadOnly<uint8> _errPort = 0x1F1;
            const PortWriteOnly<uint8> _funcPort = 0x1F1;
            const Port<uint8> _secCntPort = 0x1F2;
            const Port<uint8> _lbaLoPort = 0x1F3;
            const Port<uint8> _lbaMidPort = 0x1F4;
            const Port<uint8> _lbaHiPort = 0x1F5;
            const Port<uint8> _drivePort = 0x1F6;
            const PortReadOnly<uint8> _statusPort = 0x1F7;
            const PortWriteOnly<uint8> _cmdPort = 0x1F7;
            bool _readOneSector(uint idx, byte* dst);
            bool _writeOneSector(uint idx, byte* src);
        public:
            bool readSector(uint idx, uint cnt, byte* dst);
            bool writeSector(uint idx, uint cnt, byte* src);
    };

    #endif
    +

    头文件中的函数定义则都存放在hdd.cpp中，完整的内容如下：

    +
    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
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    #include "hdd.h"

    bool HDDManager::_readOneSector(uint idx, byte* dst) {
        _secCntPort.write(0x01);    //Read 1 sector
        _lbaLoPort.write((uint8)idx);
        _lbaMidPort.write((uint8)(idx >> 8));
        _lbaHiPort.write((uint8)(idx >> 16));
        _drivePort.write(((uint8)(idx >> 24)) | 0xE0);
        _cmdPort.write(0x20);
        while(true) {
            HDDStatusFlag status = _statusPort.read();
            if(status.contains(HDDStatusFlag::ERR_OCCURRED)) {
                return false;
            }
            if(status.contains(HDDStatusFlag::DATA_READY)) {
                break;
            }
        }
        for(int i = 0; i < 512; i += 2) {
            uint16 tmpDat = _datPort.read();
            *(uint16*)(dst + i) = tmpDat;
        }
        return true;
    }

    bool HDDManager::_writeOneSector(uint idx, byte* src) {
        _secCntPort.write(0x01);
        _lbaLoPort.write((uint8)idx);
        _lbaMidPort.write((uint8)(idx >> 8));
        _lbaHiPort.write((uint8)(idx >> 16));
        _drivePort.write(((uint8)(idx >> 24)) | 0xE0);
        _cmdPort.write(0x30);
        while(true) {
            HDDStatusFlag status = _statusPort.read();
            if(status.contains(HDDStatusFlag::ERR_OCCURRED)) {
                return false;
            }
            if(status.contains(HDDStatusFlag::DATA_READY)) {
                break;
            }
        }
        for(int i = 0; i < 512; i += 2) {
            uint16 tempDat = *(uint16*)(src + i);
            _datPort.write(tempDat);
        }
        return true;
    }

    bool HDDManager::readSector(uint idx, uint cnt, byte* dst) {
        uint offset = 0;
        for(uint i = 0; i < cnt; i++) {
            if(!_readOneSector(idx + i, (byte*)(dst + offset))) {
                uint8 err = _errPort.read();
                memcpy(dst, &err, 8);
                return false;
            }
            offset += 512;
        }
        return true;
    }

    bool HDDManager::writeSector(uint idx, uint cnt, byte* src) {
        uint offset = 0;
        for(uint i = 0; i < cnt; i++) {
            if(!_writeOneSector(idx + i, (byte*)(src + offset))) {
                uint8 err = _errPort.read();
                memcpy(src, &err, 8);
                return false;
            }
            offset += 512;
        }
        return true;
    }
    +

    现在，如果想要从硬盘中读取某个或是某几个扇区，例如，读取5~12扇区，则可以调用HDDManager中的readSectors函数如下：

    +
    1
    2
    3
    4
    5
    //Request buffer
    byte buffer[512 * 8];
    memset(buffer, 0, 512 * 8);
    //Read sectors
    HDDManager().readSectors(5, 8, buffer);
    +

    可以看到，代码明显比原先使用汇编时更加地简洁，也更易于阅读，这也就是编写驱动的目的。

    +

    抽象FAT文件系统

    +

    在BootLoader开启了保护模式之后，所有的一切操作，包括上一小节中编写的驱动都是在为了内核的加载而铺路。

    +

    加载：
    +这里及后文中说的加载，都包括了将内核编译后的输出文件读入内存中以及将内核的各个部分放置在正确的物理地址处这两个步骤

    +
    +

    加载这一个环节又自然离不开将内核编译后的可执行代码从硬盘读入内存的步骤

    +

    在学校教程的实现中，内核被编译为裸二进制文件，也就是.bin文件，像MBR和BootLoader那样直接写入硬盘对应的扇区。在读取的时候，由于写入的起始扇区和扇区数量都已知，所以可以直接从硬盘读取对应的扇区到内存中。由于内核已经被编译为裸二进制文件，只需要将整个文件读取到对应的地址处就完成了内核的加载操作，而不需要额外的操作。

    +

    固然，使用这个方式是简单而且方便的，但我始终觉得这样不够优雅。于是我简单地了解了Linux中一个叫做grub的启动引导程序，简单来讲，grub的启动分为了三个阶段：

    +
      +
    1. 第一个阶段 (stage 1) 就基本相当于我们所编写的MBR部分，其负责从硬盘上加载中间阶段 (stage 1.5) 的代码的首扇区，也就相当于我们的BootLoader
      2. +
    2. 这个中间阶段 (stage 1.5) 首扇区代码负责将剩余代码载入内存，之后剩余代码会找到活动分区下/boot/grub/目录中的启动程序，也即第二阶段程序 (stage 2)，然后加载到内存运行
      3. +
    3. 在第二阶段 (stage 2) 中，程序会解析/boot/grub/grub.cfg文件，显示一个启动菜单给用户，并且负责加载对应系统中的内核运行
      4. +
    +

    GNU GRUB
    +关于grub的更多信息，可以查看Wikipedia上关于grub的页面

    +
    +

    由于grub在中间阶段就引入了对文件系统的加载，从而可以从分区目录中读取需要的文件，看起来就比直接读取裸二进制文件要优雅得多了。因此我决定放弃学校教程的思路，转而在KernelLoader中实现一个简单版的grub程序，其可以从分区的/system/目录下找到内核文件并加载。

    +

    为了能够在KernelLoader中读取分区中的目录和文件信息，就必须要让代码能够解析分区上的文件系统，由于FAT是一个成熟且简单的文件系统，所以在实验中硬盘采用了FAT格式进行格式化。

    +

    尽管文件系统中存储的文件不尽相同，但对于同一个格式的文件系统，它们又都有着相同之处，例如文件系统包含了哪些结构，文件在文件系统中是怎样被组织的等等，这些不同中的相同之处就是我们解析文件系统的关键之处。

    +

    我们现在所需要做的就是用代码表示出这些相同的部分，并探究这些相同部分中的信息如何给文件的读取以提示，如何帮助我们了解文件系统中的内容。在下一章中，我们会更进一步，了解如何通过这部分信息从文件系统中读取需要的文件。

    +

    抽象：
    +通过代码去表现共同点，并用接口从共同点中提取出需要的信息，从而能够去解析那些特异的数据，这其实就是抽象的过程。

    +
    +

    简述文件系统与FAT

    +

    参考资料
    +如果想要了解关于文件系统的更为权威、详细的信息，可以阅读课本《操作系统概念》中第四部分关于文件系统的内容，我强烈建议先完成这部分的阅读再继续后面的实验。
    +除此之外，Bilibili上南京大学操作系统课程中关于FAT和UNIX文件系统知识的讲解是不错的视频资料，其前半部分讲解了文件系统的原理以及FAT的一些基础知识。

    +
    +

    文件系统是对文件的一种组织形式，所以文件固然也就是文件系统中至关重要的部分，了解文件系统首先就要了解文件的构成。

    +

    不论是哪种类型的文件，不论是.doc、.ppt还是.txt抑或是.bin，在硬盘的视角来看，它们中的数据实际上都是一系列二进制的数据块，而类别的区别只在于这些数据内部的组织形式，并不会让它们看起来是除了二进制数据块以外的其他样子。

    +

    但是如果一个文件只有数据块又不太够，文件名称是用户用以区分不同文件的关键信息，文件名称有时候对于文件系统来说太复杂了，所以文件系统会用一些特殊的方式记录用户提供的文件名称并通过其来识别不同的文件，这种记录有时候会呈现以标识符的形式，在FAT文件系统中则是一系列字符串。

    +

    除此之外，文件还需要一些其他的信息，例如其类型、数据在硬盘上的位置、尺寸、访问权限、创建或修改日期等等。

    +

    可见，文件由两个关键的部分组成，一个是文件的数据，也就是一系列二进制数据块，另一个则是文件的信息，它用来区分不同的文件并在硬盘上定位到文件数据的位置。

    +

    图 1

    +

    在文件系统组织文件的时候，其实际上就是在建立索引文件的数据结构，由于文件是由两部分构成的，文件系统中也就存在着两种主要的数据结构，分别用来索引文件的这两个组成部分。

    +

    其中一个数据结构用来索引文件的信息，这部分数据结构一般呈现树形的结构，文件系统中的文件目录就是由这个数据结构所维护的，树中每个节点都存储着一个文件或是目录的信息。

    +

    图 3

    +

    另一个数据结构则用于通过文件的信息来索引文件的数据，由于一个文件可能跨越数个甚至数十、数百个扇区，由于文件时时刻刻都可能会被更改，所以没有办法预先给文件分配一段固定的、连续的、大小适当的空间，因此文件的数据往往分散在磁盘的各个位置，这时就需要一个数据结构来将这些游离的数据块串接起来。说到这里，可能大家就已经能猜到，这部分数据结构一般以链表的形式出现。每一个文件块都对应着一个下一文件块的位置信息，而第一个文件块的位置信息则存储于文件的信息中。

    +

    下图表示了一个文件系统磁盘中可能的样子：

    + +

    图 2

    +

    由上图可以看出，目录树的遍历方式是要与数据结构中树的遍历方式有很大不同的。每一个节点实际上都对应着一个存储着其子节点的文件的信息的数组，通过这个数组，可以获得子节点对应文件的首块信息，再依据链表就能够获得全部的文件数据。只有当取得了全部的文件数据，才可以进入下一层的节点。

    +

    简单来说，就是在/目录下，我们只能得到system/和home/的信息，但是我们不能从这些信息中直接得到system/下或是home/下有什么文件，除非我们把它们的数据完整地读取出来。

    +

    而在一般的数据结构中，对于根节点root，我们只需要访问child = root->children[0]就可以获得整个子节点，得到的child就包含了其所有的子节点数据，而不需要额外的加载操作。

    +

    现在，假设我们需要访问/system/kernel.elf文件，那么就需要

    +
      +
    1. 首先从树的根部开始，找到类型为目录，名称为system的信息
      2. +
    2. 从信息中读取出目录数据的第一个块#8，并根据链表中的信息读入整个目录，由于这里只有一个块，所以就读入#8
      3. +
    3. 在目录的数据中找到类型为文件，名称为kernel.elf的信息
      4. +
    4. 从信息中读出文件数据的第一个块#4，并根据链表读入#6，得到整个文件。
      5. +
    +

    不过，为了提高文件读写的速度，系统一般会维护一个打开的文件表 (Open-file table) 用于维护所有打开的文件的信息，所以一般来说，当打开一个文件的时候，除了会将它的全部数据就被读取到内存中，还会将其信息添加到打开文件表中，后续所有的增删改都只会对内存中的数据起作用，直到文件关闭时才再次写回磁盘。这样就避免了每次读写过程中对文件数据的定位以及读取。

    +

    好戏还在后面
    +关于操作系统如何维护打开文件表，以及更多更为复杂的操作，将会留到内核中实现

    +
    +

    不过，上面只是对文件系统的一种简单的概述，不同的文件系统会有不同的组织文件的方式，但核心总还是离不开怎样组织文件的数据以及如何通过文件的信息索引到文件的数据，区别大抵是数据结构的差异以及具体实现上的差异。

    +

    例如，在上世纪出现的FAT中，由于软盘随机读取的性能奇差，所以如果像上文中图片绘制的那样，在文件数据块的末尾添加上下一个文件块的信息，糟糕的问题就会出现：如果尝试在文件尾部添加些什么，那需要遍历之前所有的文件块才能知道最后一个文件块在哪个位置！

    +

    为此，工程师们将所有文件块中关于下一个块的信息独立出来，存放在磁盘中的一个连续的空间内，这个空间也被称作文件分配表 (File Allocation Table)，也就是FAT实际的意义。这样，只需要提前把这一部分空间读取到内存中，就可以很快地定位到文件任意个块的信息了。

    +

    图 1

    +

    同时，这样做还有一个好处，一个512字节或是其整数倍的块需要分配几个字节给下一个块的块号，导致每个文件块实际数据大小不是2的幂，现在由于将这部分信息独立出来，所以每一个文件块都是完整的512字节或是512字节的倍数。

    +

    但是，如果每个数据块只占据1个扇区的话，对于大磁盘来说，需要的块号还是太多了，于是工程师就提出了簇 (cluster) 的概念，一簇由许多个扇区组成，而这个簇就相当于前文中的数据块。

    +

    这样，在FAT中存储簇号就大大减少了FAT的大小，虽然增加了碎片，但是提升了文件读写的效率。

    +

    碎片：
    +当一个簇很大的时候，例如4KiB，如果一个文件的大小为4KiB + 1B，则仍然需要为其分配8KiB的空间，也就是两簇。这就使得第二簇中几乎所有的空间都被浪费了，这部分空间就被成为碎片

    +
    +

    第一篇文档

    +

    在了解了文件系统是怎样组织和存储文件之后，对于如何从文件系统中读取文件应该有了思路。

    +

    但是细细一想又会发现很多问题，例如：根目录存储在磁盘的哪个位置、如何知道一个簇有多大、文件名是如何存储的、怎样才代表当前的簇是文件的最后一个簇等等

    +

    这便是因为文件系统很多具体的细节还没有落实，程序还无法从现有的文件系统中获得需要的数据。而这就是本节的目的，通过阅读微软关于FAT文件系统的规范文档，对FAT文件系统进行抽象，并且提供接口来解决上面提到的种种问题。

    +

    下载FAT规范文档
    +可以从我的服务器上下载我做过简单批注的版本
    +也可以通过原链接下载官方版本

    +
    +

    定义与注解

    +

    第一章大体可以略过，其中较为重要的概念如下：

    + +

    卷结构

    +

    第二章主要介绍了FAT格式卷的结构，除了上文中提到的用来存储下一个簇信息的FAT区域 (FAT Region) 以及存储文件数据的区域 (File and Directory Data Region) ，还包括了一个保留区 (Reserved Region) 和一个根目录区 (Root Directory Region) 。

    +

    根目录区在FAT32格式的卷上不存在

    +
    +

    一个FAT格式的卷结构大概长得就像下面这样

    +

    图 4

    +

    陷阱：小端模式
    +由于所有的FAT文件系统都是为IBM PC机器的架构所设计，因此其数据结构在硬盘上的存储方式都是小端模式。

    +
    +

    BPB数据结构

    +

    在FAT格式的卷的首扇区，有一个叫做BPB (Bios Parameter Block) 的数据结构，其主要存储了关于当前卷上FAT文件系统的关键信息，包括了文件系统各个区域的首扇区号，以及簇大小等等。

    +

    注：
    +首扇区并不是所有的内容都属于BPB结构体的范畴，在后续的介绍中，以 BPB_ 开头的域才是属于BPB结构体的域
    +In the following description, all the fields whose names start with BPB_ are part of the BPB. All the fields whose names start with BS_ are part of the boot sector and not really part of the BPB.

    +
    +

    对于FAT12/16和FAT32，它们的BPB结构在首36字节上完全一致：

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    域名称偏移大小描述限制
    BS_jmpBoot03跳转到启动代码处执行的指令
    由于实验中启动代码位于MBR，不会从这里进行启动，因此可以不用关心这个域实际的内容    		一般为0x90**EB或是0x****E9
    BS_OEMName38OEM厂商的名称，同样与实验无关，不需要关心-
    BPB_BytsPerSec112每个扇区的字节数只能是512、1024、2048或4096
    BPB_SecPerClus131每个簇的扇区数量只能是1、2、4、8、16、32、64和128
    BPB_RsvdSecCnt142保留区域的扇区数量
    可以用来计算FAT区域的首扇区位置    		不能为0，可以为任意非0值
    可以用来将将数据区域与簇大小对齐（使数据区域的起始偏移位于簇大小的整数倍处）
    BPB_NumFATs161FAT表数量一般为2，也可以为1
    BPB_RootEntCnt172根目录中的条目数
    指根目录中包含的所有的条目数量，包括有效的、空的和无效的条目
    可以用来计算根目录区所占用的字节数    		FAT32： 必须为0
    FAT12/16： 必须满足(BPB_RootEntCnt×32)≡0  (mod  2)(BPB\_RootEntCnt \times 32) \equiv 0\;(mod\;2)
    BPB_TotSec1619216位长度卷的总扇区数
    对于FAT32和更大容量的存储设备有额外的BPB_TotSec32域
    应当是为了维持BPB结构的一致性而仍然保留了这个域    		FAT32： 必须位0
    FAT12/16： 如果总扇区数小于0x10000（也就是能用16位表示）则使用此域表示，否则也使用BPB_TotSec32域
    BPB_Media211似乎是设备的类型
    与实验无关，所以可以不用特别关心    		合法取值包括0xF0、0xF8、0xF9、0xFA、0xFB、0xFC、0xFD、0xFE和0xFF
    本地磁盘（不可移动）的规定值为0xF8
    可移动磁盘的往往使用0xF0
    BPB_FATSz16222单个FAT表占用的扇区数
    只用于FAT12/16格式的文件系统    		FAT32： 必须为0
    FAT12/16： 正整数值
    BPB_SecPerTrk242每个扇区的磁道数
    与0x13中断相关
    只与具有物理结构（如磁道、磁盘等）并且对0x13中断可见的存储介质有关
    与实验无关，可以不用关心    		-
    BPB_NumHeads262磁头数量
    同样与0x13中断相关，实验不会使用，所以可以不用关心    		-
    BPB_HiddSec284分区前隐藏的扇区数
    在文档中描述这个域为同样只与对0x13中断可见的存储介质有关，但在实验过程中发现对于一个多分区的磁盘，这个域对应了分区首扇区在整个磁盘中的扇区号，例如首扇区位于磁盘2048扇区（从0开始计算分区号）的分区，其BPB_HiddSec域值就为2048    		-
    BPB_TotSec3232432位长度卷的总扇区数
    用来描述FAT32卷中的总扇区数或是扇区数多于0x10000的FAT12/16卷中的总扇区数    		FAT32： 必须为非零整数值
    FAT12/16： 如果扇区数大于0x10000，则为扇区数，否则必须为0
    +

    从第37字节开始，FAT12和FAT16卷上的BPB结构如下：

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    域名称偏移大小描述限制
    BS_DrvNum361用于0x13中断的驱动器号，可以不用关心应当设置为0x80或是0x00
    BS_Reserved1371保留位必须为0
    BS_BootSig381用来检验启动扇区的完整性的签名，可以不用关心如果BS_VolID、BS_VolLab和BS_FilSysType三个域都存在有效的值 (present)，则置为0x29
    BS_VolID394卷的序列号，可以不用关心-
    BS_VolLab4311卷标，可以不用关心
    在文档中，要求与根目录下的卷标描述文件保持内容一致，但实际上在测试中往往卷标描述文件中存储的是真实的卷标而这个域的内容仍为缺省值"No NAME"    		缺省值为"NO NAME"
    BS_FilSysType548用来描述文件系统类型，但不能用来作为判断文件系统类型的依据“FAT12”、“FAT16"或是"FAT32”
    -62448空余，置零必须为0
    Signature_word5102校验位设置为0xAA55
    -512*如果BPB_BytsPerSec>512BPB\_BytsPerSec \gt 512则存在此域，全部置零必须为0
    +

    相对的，从37字节开始，FAT32文件系统中BPB的结构如下：

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    域名称偏移大小描述限制
    BPB_FATSz32364单个FAT表占用的扇区数
    只用于FAT32格式的文件系统    		非负整数值
    BPB_ExtFlags402标志位[0:3]： 活动FAT表的标号（按照从零开始计数）
    [4:6]：保留位
    [7]：当FAT在运行时会自动镜像写入其他FAT表时，置零，否则对于只有一个活动的FAT表时置位
    BPB_FSVer422奇怪的版本号域，文档中写了半天描述最后要求置零…必须为0
    BPB_RootClus444根目录的首簇簇号BPB_RootClus>2BPB\_RootClus \gt 2
    BPB_FSInfo482FSInfo结构体所在的首扇区号一般为1
    BPB_BkBootSec502备份启动扇区的扇区号
    由于现在的硬盘不像当年软盘那样易失，所以关于备份相关的域实际都可以不用关心，因为用不上    		设置为0或6
    BPB_Reserved5212保留位必须为0
    BS_DrvNum641用于0x13中断的驱动器号，可以不用关心应当设置为0x80或是0x00
    BS_Reserved1651保留位必须为0
    BS_BootSig661用来检验启动扇区的完整性的签名，可以不用关心如果BS_VolID、BS_VolLab和BS_FilSysType三个域都存在有效的值 (present)，则置为0x29
    BS_VolID674卷的序列号，可以不用关心-
    BS_VolLab7111卷标，可以不用关心
    在文档中，要求与根目录下的卷标描述文件保持内容一致，但实际上在测试中往往卷标描述文件中存储的是真实的卷标而这个域的内容仍为缺省值"No NAME"    		缺省值为"NO NAME"
    BS_FilSysType828用来描述文件系统类型，但不能用来作为判断文件系统类型的依据“FAT12”、“FAT16"或是"FAT32”
    -90420空余，置零必须为0
    Signature_word5102校验位设置为0xAA55
    -512*如果BPB_BytsPerSec>512BPB\_BytsPerSec \gt 512则存在此域，全部置零必须为0
    +

    文档在接下来的部分介绍了如何初始化一个FAT卷，由于目前只需要读取FAT卷，所以可以忽略章节3.4。

    +

    在3.5章节中文档就介绍了如何在装载卷时判断FAT的类型，其中关键的判断算法为

    +
    1
    2
    3
    4
    5
    6
    7
    if(CountofClusters < 4085) {
      /* Volume is FAT12 */
    } else if(CountofClusters < 65525) {
      /* Volume is FAT16 */
    } else {
      /* Volume is FAT32 */
    }
    +

    也就是说，FAT的类型只与簇的数量有关，而与磁盘的大小、扇区数量，包括BPB中的BPB_FilSysType域都无关，其中

    + +

    在明白了BPB的结构之后，就可以开始着手对BPB进行抽象了。

    +

    最初我采用了两个不同的类来分别对FAT12/16和FAT32的BPB进行抽象，但这样的问题也是十分明显的，在我不确定FAT实际的类型时我把首512字节视为哪个数据结构都不是很合理。但如果我不通过抽象后的数据结构去解析首512字节，我又没办法判断究竟是那种FAT类型。为了解决这个矛盾，我甚至由引入了一个类来描述FAT12/16与FAT32相同的37字节数据，这就导致代码越来越乱，看起来也让人云里雾里的。

    +

    但后来就注意到虽然对于FAT12/16和FAT32，它们在结构上存在一定的不同，但其BPB有效的部分都是首扇区的首512字节（如果扇区大于512字节后面的也仍然填充0，可以忽略）。

    +

    同时，BPB需要提供的主要功能也是基本相同的，主要的区别基本都在于域宽是16位还是32位。

    +

    如果在函数接口的上不区分FAT12/16和FAT32，只在函数的实现上根据FAT12/16和FAT32的不同从512字节的数据中取出对应需要的域，就可以实现功能的统一，调用函数的代码就只需要关心需要使用FAT的哪种信息，而不需要再关心FAT的类型。

    +

    例如，BPB_FATSz16和BPB_FATSz32实质上都是为了提供FAT表的大小，它们是可以统一到一个接口uint32 fatSize()上的，需要关心FAT表大小的代码不需要关心具体是哪种格式的FAT系统，只需要调用fatSize()既可以取得需要的数值，具体的解析操作交给了函数本身去区分和实现。

    +

    阅读上表，可以总结出BPB所需要提供的所有接口：

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    uint16 bytesPerSector();
    uint8 sectorsPerCluster();
    uint16 sectorsPerTrack();
    uint16 headCount();
    uint16 reservedSectorCount();
    uint32 hiddenSectorCount();
    uint32 totalSectors();
    uint8 fatCount();
    uint32 fatSize();
    uint8 activeFAT();        //FAT32 only
    bool isFATMirrored();     //FAT32only
    uint16 rootEntryCount();  //FAT16 only
    uint32 rootCluster();     //FAT32 only
    char* oemName();
    uint8 mediaType();
    uint8 driveNumber();
    bool hasExtendedBootSignature();
    uint32 volumeSerialNumber();
    char* volumeLabel();
    char* fsTypeLabel();
    uint16 fsInfoSector();    //FAT32 only
    +

    可以注意到，有些函数是只有特定的FAT格式才存在的，这时如果调用者强行调用了一个当前FAT格式不存在的接口，实质上是不安全的，因为这样并不会产生任何错误，同时还会返回一个不确定的值。但这样的弊端比起这种实现的优点而言就显得微不足道了。

    +

    更进一步地说，由于调用接口的代码只能是操作系统的代码所调用，而操作系统代码只能由我们所完成，所以我们可以通过主动避免错误的调用来避开这个风险，抑或是，可以在函数内额外判断一次FAT类型，并在不合法的调用处陷入死循环等等，有很多可以解决的方法。

    +

    除了解析BPB数据的接口以外，由于BPB主要的作用是计算FAT文件系统各个区域的大小、偏移量等信息，所以也不妨将这部分琐碎的代码纳入类的函数作为接口提供给其他程序：

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    bool isFAT12();
    bool isFAT16();
    bool isFAT32();
    uint32 fatEntrySize();
    uint32 fatFrstSec();
    uint32 fatFrstSecAbsolute();
    uint32 fatTotalSec();
    uint32 rootDirFrstSec();
    uint32 rootDirFrstSecAbsolute();
    uint32 rootDirTotalSec();
    uint32 dataFrstSec();
    uint32 dataFrstSecAbsolute();
    uint32 dataTotalSec();
    uint32 totalClusters();
    uint32 secOfCluster(uint32 clus);
    uint32 absoluteSecOfCluster(uint32 clus);
    +

    于是，完整的BPB头文件fatbpb.h如下：

    +
    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
    51
    52
    53
    #include "types.h"

    #ifndef _FAT_BPB_H_
    #define _FAT_BPB_H_

    class FATBPB {
        private:
            byte _data[512];
        public:
            FATBPB(uint32 bpbFrstSec);
        public:
            //Metadata parsing
            uint16 bytesPerSector();
            uint8 sectorsPerCluster();
            uint16 sectorsPerTrack();
            uint16 headCount();
            uint16 reservedSectorCount();
            uint32 hiddenSectorCount();
            uint32 totalSectors();
            uint8 fatCount();
            uint32 fatSize();
            uint8 activeFAT();      //FAT32 only
            bool isFATMirrored();       //FAT32only
            uint16 rootEntryCount();//FAT16 only
            uint32 rootCluster();   //FAT32 only
            char* oemName();
            uint8 mediaType();
            uint8 driveNumber();
            bool hasExtendedBootSignature();
            uint32 volumeSerialNumber();
            char* volumeLabel();
            char* fsTypeLabel();
            uint16 fsInfoSector();  //FAT32 only
            //Basic calculation
            bool isFAT12();
            bool isFAT16();
            bool isFAT32();
            uint32 fatEntrySize();
            uint32 fatFrstSec();
            uint32 fatFrstSecAbsolute();
            uint32 fatTotalSec();
            uint32 rootDirFrstSec();
            uint32 rootDirFrstSecAbsolute();
            uint32 rootDirTotalSec();
            uint32 dataFrstSec();
            uint32 dataFrstSecAbsolute();
            uint32 dataTotalSec();
            uint32 totalClusters();
            uint32 secOfCluster(uint32 clus);
            uint32 absoluteSecOfCluster(uint32 clus);
    };

    #endif
    +

    具体的函数实现则放在fatbpb.cpp中如下：

    +
    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
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    137
    138
    139
    140
    141
    142
    143
    144
    145
    146
    147
    148
    149
    150
    151
    152
    153
    154
    155
    156
    157
    158
    159
    160
    161
    162
    163
    164
    165
    166
    167
    168
    169
    170
    171
    172
    173
    174
    175
    176
    177
    178
    179
    180
    181
    182
    183
    184
    185
    186
    187
    188
    189
    190
    191
    192
    193
    194
    195
    196
    197
    198
    199
    200
    201
    202
    203
    204
    205
    206
    207
    208
    209
    210
    211
    212
    213
    214
    215
    216
    217
    218
    219
    220
    221
    222
    223
    224
    225
    226
    227
    228
    229
    230
    231
    232
    233
    234
    235
    236
    237
    238
    239
    240
    241
    242
    243
    244
    245
    246
    247
    248
    249
    250
    251
    252
    253
    254
    255
    256
    257
    258
    259
    260
    261
    262
    263
    264
    265
    266
    267
    268
    269
    270
    271
    272
    273
    274
    275
    276
    277
    278
    279
    280
    281
    282
    283
    284
    285
    286
    287
    288
    289
    290
    291
    292
    293
    294
    295
    296
    297
    298
    299
    300
    301
    302
    303
    304
    305
    306
    307
    308
    309
    310
    311
    312
    313
    314
    315
    316
    317
    318
    319
    320
    321
    322
    323
    324
    325
    326
    327
    328
    329
    330
    331
    332
    333
    334
    335
    336
    337
    338
    339
    340
    341
    #include "fatbpb.h"
    #include "hdd.h"

    //Read the first sector of the volume into buffer
    //@param {uint32} bpbFrstSec : The first sector of the bpb region
    FATBPB::FATBPB(uint32 bpbFrstSec) {
        HDDManager().readSector(bpbFrstSec, 1, _data);
    }

    //Returns count of bytes per sector of the disk
    //@return {uint16} : following values: 512, 1024, 2048 or 4096
    uint16 FATBPB::bytesPerSector() {
        return *(uint16*)(&_data[11]);
    }

    //Returns number of sectors per allocation unit
    //@return {uint8} : A power of 2 that is greater than 0.
    //                  Legal values are 1, 2, 4, 8, 16, 32, 64 and 128
    uint8 FATBPB::sectorsPerCluster() {
        return _data[13];
    }

    //Returns sectors per track for interrupt 0x13.
    //This is only relevant for media that have a geometry and are visible
    //on interrupt 0x13
    //@return {uint16} : sectors per track of the media
    uint16 FATBPB::sectorsPerTrack() {
        return *(uint16*)(&_data[24]);
    }

    //Returns the number of heads of the media for interrupt 0x13.
    //This is only relevant as discussed earlier for [sectorsPerTrack()]
    //@return {uint32} : One based number for number of heads
    //                   For example, on a 1.44MB 3.5-inch floppy drive this
    //                   value is 2
    uint16 FATBPB::headCount() {
        return *(uint16*)(&_data[26]);
    }

    //Returns the number of reserved sectors in the reserved region of the volume
    //starting at the first sector of the volume, which is also the size of bios 
    //parameter block in sectors
    //@return {uint16} : Non-zero value of the number of reserved sectors
    uint16 FATBPB::reservedSectorCount() {
        return *(uint16*)(&_data[14]);
    }

    //Returns the count of hidden sectors preceding the partition that contains
    //this FAT volume. This method is generally only relevant for media visible
    //on interrupt 0x13
    //@return {uint32} : The sectors preceding the partition
    uint32 FATBPB::hiddenSectorCount() {
        return *(uint32*)(&_data[28]);
    }

    //Returns the 32-bit total count of sectors on the volume. The count includes
    //the count of all sectors in all four regions of the volume
    //@return {uint32} : The total count of sectors
    uint32 FATBPB::totalSectors() {
        //It should be noted that for volumes that contain more than or equal to 0x10000
        //sectors, BPB_TotalSec32 field is used to store the total sectors count. In other
        //circumstances, BPB_TotalSec16 field is used to store the total sectors count
        //
        //In addition, BPB_TotalSec32 field should only be considered valid if BPB_TotalSec16
        //is zero
        return *(uint16*)(&_data[19]) == 0 ? *(uint32*)(&_data[32]) : (uint32)(*(uint16*)(&_data[19]));
    }

    //Returns the count of file allocation tables (FATs) on the volume
    //@return {uint8} : The count of FATs. A value of 2 is recommended although 1 is acceptable
    uint8 FATBPB::fatCount() {
        return _data[16];
    }

    //Returns the 32-bit count of sectors occupied by one FAT
    //@return {uint32} : The sectors occupied by one FAT
    uint32 FATBPB::fatSize() {
        //It should be noted that for FAT12/FAT16 volumes the sectors occupied by one FAT
        //is stored in 16-bit BPB_FATSz16 field while for FAT32 volumes the value is stored
        //in 32-bit BPB_FATSz32 field.
        uint32 fatSz16 = (uint32)(*(uint16*)(&_data[22]));
        if(fatSz16 != 0) {
            return fatSz16;
        }
        else {
            return *(uint32*)(&_data[36]);
        }
    }

    //Returns the active FAT on the volume
    //It should be noted that this method is FAT32 only
    //@return {uint8} : Zero-based number of active FAT, only valid if mirroring is disabled
    uint8 FATBPB::activeFAT() {
        return _data[40] & 0xF;
    }

    //Returns whether mirroring is disabled on the volume
    //It should be noted that this method is FAT32 only
    //@return {bool} : True means the FAT is morrored at runtime into all FATs.
    //                 False means only one FAT is active, it is the one referenced by
    //                 [activeFAT()]
    bool FATBPB::isFATMirrored() {
        return (_data[40] & 0x80) != 0;
    }

    //Returns the count of 32-byte directory entries in the root directory
    //@return {uint16} : The count of directory entries in the root directory.
    //                   This value should always specify a count that when multiplied
    //                   by 32 results in an even multiple of [bytesPerSecter()]
    uint16 FATBPB::rootEntryCount() {
        return *(uint16*)(&_data[17]);
    }

    //Returns the cluster number of the first cluster of the root directory
    //It should be noted that this method is FAT32 only
    //@return {uint32} : the root cluster number
    uint32 FATBPB::rootCluster() {
        return *(uint32*)(&_data[44]);
    }

    //Returns the OEM name identifier in the bios parameter block
    //@return {char*} : The pointer to the field containing the OEM name in the buffer
    char* FATBPB::oemName() {
        return (char*)(&_data[3]);
    }

    //Returns the media type
    //@return {uint8} : Legal values are 0xF0, 0xF8, 0xF9, 0xFA, 0xFB, 0xFC, 0xFD, 0xFE and 0xFF
    //                  0xF8 is standard value for fixed media while 0xF0 is for removable media
    uint8 FATBPB::mediaType() {
        return _data[21];
    }

    //Returns the drive number for interrupt 0x13
    //@return {uint8} : 0x80 or 0x00
    uint8 FATBPB::driveNumber() {
        //It should be noted that the field containing the value has different offset on FAT12/16
        //volumes and FAT32 volumes
        //On FAT12/16 volumes the field has an offset of 36 while on FAT32 volumes has an offset
        //of 64
        if(isFAT32()) {
            return _data[64];
        }
        else {
            return _data[36];
        }
    }

    //Check whether the volume contains the extended boot signature which indicates
    //the BS_VolOD, BS_VolLab and BS_FilSysType fields are present
    //@return {bool} : Ture for the extended boot signature value is set to 0x29
    bool FATBPB::hasExtendedBootSignature() {
        //It should be noted that the field containing the value has different offset on FAT12/16
        //volumes and FAT32 volumes
        //On FAT12/16 volumes the field has an offset of 38 while on FAT32 volumes has an offset
        //of 66
        if(isFAT32()) {
            return _data[66] == 0x29;
        }
        else {
            return _data[38] == 0x29;
        }
    }

    //Returns the volume serial number for volume tracking on removable media.
    //It should be noted that this value is only present when [hasExtendedBootSignature()]
    //function returns a true value.
    //@return {uint32} : Volume serial number
    uint32 FATBPB::volumeSerialNumber() {
        //It should be noted that the field containing the value has different offset on FAT12/16
        //volumes and FAT32 volumes
        //On FAT12/16 volumes the field has an offset of 39 while on FAT32 volumes has an offset
        //of 67
        if(isFAT32()) {
            return *(uint32*)(&_data[67]);
        }
        else {
            return *(uint32*)(&_data[39]);
        }
    }

    //Returns the volume label
    //@return {char*} : The pointer of the volume label stored in the buffer
    char* FATBPB::volumeLabel() {
        //It should be noted that the field containing the value has different offset on FAT12/16
        //volumes and FAT32 volumes
        //On FAT12/16 volumes the field has an offset of 43 while on FAT32 volumes has an offset
        //of 71
        if(isFAT32()) {
            return (char*)(&_data[71]);
        }
        else {
            return (char*)(&_data[43]);
        }
    }

    //Returns the file system type string
    //@return {char*} : The pointer of the fs type string, the string should be one of the
    //                  strings: "FAT", "FAT12", "FAT16" or "FAT32"
    char* FATBPB::fsTypeLabel() {
        //It should be noted that the field containing the value has different offset on FAT12/16
        //volumes and FAT32 volumes
        //On FAT12/16 volumes the field has an offset of 54 while on FAT32 volumes has an offset
        //of 82
        if(isFAT32()) {
            return (char*)(&_data[82]);
        }
        else {
            return (char*)(&_data[54]);
        }
    }

    //Returns the sector number of FSINFO structure in the reserved area of the FAT32 volume.
    //It should be noted that this method is only available on FAT32 volumes.
    //@return {uint16} : FSINFO structure sector number, usually 1
    uint16 FATBPB::fsInfoSector() {
        return *(uint16*)(&_data[48]);
    }

    //Check whether the volume is FAT12
    bool FATBPB::isFAT12() {
        uint32 totClus = totalClusters();
        return totClus < 4085;
    }

    //Check whether the volume is FAT16
    bool FATBPB::isFAT16() {
        uint32 totClus = totalClusters();
        return totClus >= 4085 && totClus < 65525;
    }

    //Check whether the volume is FAT32
    bool FATBPB::isFAT32() {
        uint32 totClus = totalClusters();
        return totClus >= 65525;
    }

    //Return the size in bytes of a fat entry
    //@return {uint32} : 12 for FAT12, 16 for FAT16, 32 for FAT32
    uint32 FATBPB::fatEntrySize() {
        uint32 totClus = totalClusters();
        if(totClus < 4085) {
            return 12;
        }
        else if(totClus < 65525) {
            return 16;
        }
        else {
            return 32;
        }
    }

    //Returns the first sector of first FAT
    uint32 FATBPB::fatFrstSec() {
        return reservedSectorCount();
    }

    //Returns the ABSOLUTE sector number of first FAT
    uint32 FATBPB::fatFrstSecAbsolute() {
        return hiddenSectorCount() + reservedSectorCount();
    }

    //Returns the total sectors of FATs
    uint32 FATBPB::fatTotalSec() {
        return fatCount() * fatSize();
    }

    //Returns the first sector of the root directory region
    uint32 FATBPB::rootDirFrstSec() {
        uint32 resvdSecCnt = reservedSectorCount();
        uint32 fatSecCnt = fatTotalSec();
        return resvdSecCnt + fatSecCnt;
    }

    //Returns the ABSOLUTE sector number of the first sector of the root
    //directory region
    uint32 FATBPB::rootDirFrstSecAbsolute() {
        uint32 resvdSecCnt = reservedSectorCount();
        uint32 fatSecCnt = fatTotalSec();
        uint32 hiddenSec = hiddenSectorCount();
        return hiddenSec + resvdSecCnt + fatSecCnt;
    }

    //Returns the total sectors of root directory region
    uint32 FATBPB::rootDirTotalSec() {
        uint32 rootEntCnt = rootEntryCount();
        uint32 bytsPerSec = bytesPerSector();
        return (rootEntCnt * 32 + (bytsPerSec - 1)) / bytsPerSec;
    }

    //Returns the first sector of data region
    uint32 FATBPB::dataFrstSec() {
        uint32 resvdSecCnt = reservedSectorCount();
        uint32 fatSecCnt = fatTotalSec();
        uint32 rootSecCnt = rootDirTotalSec();
        return resvdSecCnt + fatSecCnt + rootSecCnt;
    }

    //Returns the ABSOLUTE sector number of data region
    uint32 FATBPB::dataFrstSecAbsolute() {
        uint32 resvdSecCnt = reservedSectorCount();
        uint32 fatSecCnt = fatTotalSec();
        uint32 rootSecCnt = rootDirTotalSec();
        uint32 hiddenSec = hiddenSectorCount();
        return hiddenSec + resvdSecCnt + fatSecCnt + rootSecCnt;
    }

    //Returns the total sectors of data region
    uint32 FATBPB::dataTotalSec() {
        uint32 totSec = totalSectors();
        uint32 resvdSecCnt = reservedSectorCount();
        uint32 fatSecCnt = fatTotalSec();
        uint32 rootSecCnt = rootDirTotalSec();
        return totSec - (resvdSecCnt + fatSecCnt + rootSecCnt);
    }

    //Returns the total clusters of data region
    uint32 FATBPB::totalClusters() {
        return dataTotalSec() / sectorsPerCluster();
    }

    //Returns the sector of the given cluster
    //@param {uint32} clus : The zero-based cluster number
    //@return {uint32} : The sector number of the cluster
    uint32 FATBPB::secOfCluster(uint32 clus) {
        uint32 frstDataSec = dataFrstSec();
        uint32 clusterOffset = clus - 2;
        uint32 secPerClus = sectorsPerCluster();
        return frstDataSec + clusterOffset * secPerClus;
    }

    //Returns the ABSOLUTE sector of the given cluster
    //@param {uint32} clus : The zero-based cluster number
    //@return {uint32} : The absolute sector number of the cluster
    uint32 FATBPB::absoluteSecOfCluster(uint32 clus) {
        uint32 frstDataSec = dataFrstSec();
        uint32 clusterOffset = clus - 2;
        uint32 secPerClus = sectorsPerCluster();
        uint32 hiddenSec = hiddenSectorCount();
        return hiddenSec + frstDataSec + clusterOffset * secPerClus;
    }
    +

    FAT

    +

    回顾：
    +如果一个文件大小超过了一个簇，那么用来存储它数据的簇可能在磁盘上并不连续，为了能够将这些分散的簇连起来，文件系统一般会为每一个簇对应一个域用来保存关于它下一个簇的信息，从而就可以如同链表那样将整个文件串联在一起。在FAT中，这些域被集中存储在磁盘的一段空间内，这一段空间就叫做FAT (File Allocation Table)。

    +
    +

    对于不同的FAT格式，FAT表中每个条目 (entry) 的大小不同：

    + +

    这时候就发现了，原来FAT后面的数字就是指代的FAT表中每个条目的长度

    +

    FAT条目中可能的存储值及其含义如下，其中MAX指代磁盘中合法的最大的簇号：

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    FAT12FAT16FAT32含义
    0x0000x00000x0000000当前条目所对应的簇空闲
    0x000 ~ MAX0x0002 ~ MAX0x0000002 ~ MAX当前条目所对应的簇存在内容，并且条目的值就是下一个簇的簇号
    (MAX + 1) ~ 0xFF6(MAX + 1) ~ 0xFFF6(MAX + 1) ~ 0xFFFFFF6保留的值，不能够使用
    0xFF70xFFF70xFFFFFF7当前条目所对应的簇是损坏的簇
    0xFF8 ~ 0xFFE0xFFF8 ~ 0xFFFE0xFFFFFF8 ~ 0xFFFFFFE保留的值，有时也作为指示当前条目所对应的簇是文件的最后一个簇
    0xFFF0xFFFF0xFFFFFFF当前条目所对应的簇是文件的最后一个簇
    +

    陷阱：FAT32高四位保留
    +FAT32中的每个条目高四位都是被保留的，所以可以看到上表中FAT32对应的值只有7位。除了在格式化的时候，在其他任何时候设置FAT条目时都不应该更改原先高四位的值。

    +
    +

    陷阱：FAT表首两个条目保留
    +注意到上表中有效的FAT条目值从2开始，因为FAT表中的前两个条目是被保留的。
    +这也就导致了簇号和实际的簇产生了2的偏移：对于任意簇号NN，当在磁盘上访问实际的簇时，应当访问第N−2N-2个簇

    +
    +

    FAT表中第一个保留的条目（FAT[0]）包含了BPB_Media域中的内容，其他的位被设置为1，对于FAT32高四位同样不进行更改。例如，如果BPB_Media的值为0xF8，那么

    + +

    第二个保留的条目（FAT[1]）在格式化时会被格式化工具赋一个EOC值（具体用处不明）。对于FAT12而言，由于空间有限，所以并没有额外的标记位，对于FAT16和FAT32而言，Windows系统可能会使用高两位作为脏卷的标记位，其中最高位为ClnShutBit，如果该位置位，则意味着上一次该设备没有被正常卸载，可能需要检查文件系统的完整性；次高位为HrdErrBit，如果该位置位，则标明读写功能正常，如果置0则代表遇到了IO错误，提示一些磁盘扇区可能发生了错误。

    +

    由于FAT表相当于一个数组，因此其不需要特殊的抽象。

    +

    不过由于FAT12的特殊性，12位长度的数据并不能跟字节对齐，也就是说在FAT12中，一个条目从某个字节的中间开始，所以在根据下标从FAT从取值时可能会稍微复杂一些，在文档中也给出了具体的读取的代码。

    +

    由于具体文件的读取在KernelLoader中进行，因此这部分的内容可以留待下一个章节再详细研究。

    +

    目录结构

    +

    到目前为止，BPB以及FAT表我们都已经清楚了，这样不论是FAT12、FAT16还是FAT32，我们都可以顺利地找到根目录所在的区域并且读取根目录所包含的所有数据了：

    + +

    那么，接下来就要解决如何解析根目录内的文件了。更广泛地讲，由于根目录就像其他所有的文件目录一样，所以接下来就要解决如何读取一个目录，并且得到目录中各个文件的信息。

    +

    实际上，目录同样是一个由目录条目构成的数组，其中每一个目录条目都是一个32字节长度的数据结构，而正是这个数据结构中存储的数据描述了一个目录中存储的文件或是一个子目录的详细信息，例如它的创建日期和时间、名称或是最重要的首簇簇号等等。它的完整结构如下：

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    域名称偏移大小描述
    DIR_Name011短名称格式的文件名
    DIR_Attr111文件的属性标记
    DIR_NTRes121保留位，必须为0
    DIR_CrtTimeTenth131文件创建时间，单位为10ms
    DIR_CrtTime142文件创建时间
    DIR_CrtDate162文件创建日期
    DIR_LstAccDate182文件最近访问日期
    DIR_FstClusHI202首簇簇号高16位
    DIR_WrtTime222文件修改时间
    DIR_WrtDate242文件修改日期
    DIR_FstClusLO262首簇簇号低16位
    DIR_FileSize284文件的大小，单位为字节
    +

    其中提到了一些概念，如短名称、文件属性以及一些仍然不明确的结构，如日期和时间的表示格式，如果继续阅读，则会发现文档也一一对它们作出了解释。

    +

    短名称为一种表示文件名称的格式，其11字节长度的域被分为8字节和3字节的空间，其中11字节用来存储文件不含扩展名的部分，而后3字节用来存储文件的扩展名，在存储名字的时候，所有的字母都会以大写字母的形式存储。

    +

    同时，短名称的存储方式会在文件名长度小于最大长度时在其后面填补空格，例如FOO.BAR在存储时由于文件名为三字节，所以会在其后填补5个空格，存储为FOO BAR

    +

    除此之外，短名称还遵循以下规则：

    + +

    然而，如果文件名称很长的话，短名称就显得不太够用了，所以FAT还额外提出了长名称的解决方案，并且称存储短名称的条目为 SFNEntry，长名称的目录为 LFNEntry。

    +

    在长名称的解决方案中，一个文件会对应一个短名称的条目和一系列长名称的条目，短名称条目存储文件名称的前数个字符和扩展名，而长名称则存储文件的全部名称。

    +

    在目录中，一个文件对应的长名称条目和短名称条目连续存储，其中地址从低到高依次存储：

    + +

    其中，长名称条目的结构如下：

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    域名称偏移大小描述
    LDIR_Ord01当前条目在当前文件所有长名称条目中的顺序，从1开始计数
    如果是最后一个条目，则需要额外置位0x40
    LDIR_Name1110存储当前条目中文件名的第1~5个字符
    LDIR_Attr111文件的属性标记，与短文件名条目的属性标记域保持相同含义
    对于长文件条目，所有的属性位都应被置位
    也即ATTR_READ_ONLY | ATTR_HIDDEN | ATTR_SYSTEM | ATTR_VOLUME_ID
    LDIR_Type121必须为0
    LDIR_Chksum131校验位，用于校验当前条目是否与文件对应的短文件名条目相匹配
    LDIR_Name21412存储当前条目中文件名的第6~11个字符
    LDIR_FstClusLO262必须为0
    LDIR_Name3284存储当前条目中文件名的第12~13个字符
    +

    陷阱：LDIR_Ord从1开始
    +文件对应的第一个长文件名条目在集合中的序号为1，而不是0

    +
    +

    陷阱：长文件名使用Unicode存储
    +长文件名中的LDIR_Name1、LDIR_Name2和LDIR_Name3中存储的都是Unicode格式的文件名，一个字符占据两个字节。

    +
    +

    对于校验码，文档也提供了算法，对应到实验中的实现为：

    +
    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
    //Calculate/Return the checksum of the entry
    //It should be noted that this function BEHAVE DIFFERENTLY in SFN and LFN entries
    //@return {uint32} : Calculate checksum out of filename in SFN entries
    //@return {uint32} : Return checksum in LFN entries
    uint32 DirEntry::checkSum() {
        if(isSFNEntry()) {
            //ChkSum()
            //Returns an unsigned byte checksum computed on an unsigned byte
            //array. The array must be 11 bytes long and is assumed to contain
            //a name stored in the format of a MS-DOS directory entry

            //The following method is copied from Microsoft FAT specification
            //page 32, chapter 7.2 Checksum generation
            byte* pName = &_data[0];
            uint16 nameLen;
            uint8 sum;
            sum = 0;
            for(nameLen = 11; nameLen != 0; nameLen--) {
                //NOTE: The operation is an unsigned char rotate right
                sum = ((sum & 1) ? 0x80 : 0) + (sum >> 1) + *pName++;
            }
            return sum;
        }
        else {
            //According to Microsoft FAT specification:
            //The checksum in LFN entries is stored in LDIR_Chksum field
            //which has an offset of 13 and size of 1 byte
            return _data[13];
        }
    }
    +

    文件的属性使用按位枚举的方式表示，其中的六个二进制位分别如下：

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    属性位描述
    ATTR_READ_ONLY1 << 0文件只读
    ATTR_HIDDEN1 << 1文件隐藏
    除非用户或程序显式声明要求访问隐藏的文件，否则不应当在文件列表中被列出
    ATTR_SYSTEM1 << 2文件为系统文件
    除非用户或程序显式声明要求访问系统文件，否则不应当在文件列表中被列出
    ATTR_VOLUME_ID1 << 3文件用来描述卷标
    ATTR_DIRECTORY1 << 4文件实际上是一个目录
    ATTR_ARCHIVE1 << 5当文件被创建、重命名或修改时置位，指示文件是否被修改过
    +

    陷阱：卷标文件只能出现在根目录
    +卷标文件为根目录中描述卷标的特殊文件，其DIR_NAME域全部用来存储卷标，同时属性域为0x8，也即ATTR_VOLUME_ID，其他部分均为0。

    +
    +

    文件的日期和时间有特殊的存储格式

    +

    其中文件的日期包括三个部分：

    + +

    文件的时间同样也包括三个部分：

    + +

    可以看到，秒的精度为2s，这也就引出了CrtTimeTenth这个域，其精度为10ms，范围从0至199，正好填补了2s之间的空缺，使得精度提高到10ms

    +

    在了解了目录的结构之后，就可以着手对目录进行抽象了。由于目录本身还是相当于关于目录条目的数组，所以根本在于对目录条目进行抽象。

    +

    因为目录条目分为SFN（短文件名）和LFN（长文件名）两种类型，但其总长度一样，所以可以参考对BPB进行抽象的过程：将两种条目合并在一起，均视为DirEntry类，在调用具体函数的时候再根据条目类型的不同执行不同的判断。

    +

    其中，由于文件属性的域涉及到位枚举，而C++没有原生支持位枚举，所以需要我们手动先在头文件中实现位枚举：

    +
    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
    class DirectoryFlag {
        public:
            enum ATTRIBUTES {
                READ_ONLY   = 1,
                HIDDEN      = 1 << 1,
                SYSTEM      = 1 << 2,
                VOLUME_ID   = 1 << 3,
                DIRECTORY   = 1 << 4,
                ARCHIVE     = 1 << 5
            };
        private:
            uint8 _attr;
        public:
            DirectoryFlag();
            DirectoryFlag(uint8 flags);
        public:
            DirectoryFlag& operator=(uint8 flags);
            DirectoryFlag& operator=(const DirectoryFlag& other);
            //Judge whether two flags are equal
            bool operator==(uint8 flags);
            //Combine two flags
            DirectoryFlag operator+(uint8 flags);
            DirectoryFlag& operator+=(uint8 flags);
            //Remove flags
            DirectoryFlag operator-(uint8 flags);
            DirectoryFlag& operator-=(uint8 flags);
            //Bitwise or
            DirectoryFlag operator|(uint8 flags);
            DirectoryFlag& operator|=(uint8 flags);
            //Bitwise and
            DirectoryFlag operator&(uint8 flags);
            DirectoryFlag& operator&=(uint8 flags);
            //Reverse flags
            DirectoryFlag operator~();
            //Toggle flag bits
            DirectoryFlag& operator^=(uint8 flags);
            //Judge whether flags are contained
            bool contains(uint8 flags);
    };
    +

    并在.cpp文件中给出重载操作符的实现

    +
    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
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    DirectoryFlag::DirectoryFlag() {
        _attr = 0;
    }
    DirectoryFlag::DirectoryFlag(uint8 flags) {
        _attr = flags;
    }
    DirectoryFlag& DirectoryFlag::operator=(uint8 flags) {
        _attr = flags;
        return *this;
    }
    DirectoryFlag& DirectoryFlag::operator=(const DirectoryFlag& other) {
        _attr = other._attr;
        return *this;
    }
    //Judge whether two flags are equal
    bool DirectoryFlag::operator==(uint8 flags) {
        return _attr == flags;
    }
    //Combine two flags
    DirectoryFlag DirectoryFlag::operator+(uint8 flags) {
        uint8 newAttr = _attr | flags;
        return DirectoryFlag(newAttr);
    }
    DirectoryFlag& DirectoryFlag::operator+=(uint8 flags) {
        _attr |= flags;
        return *this;
    }
    //Remove flags
    DirectoryFlag DirectoryFlag::operator-(uint8 flags) {
        uint8 newAttr = _attr & ~(flags);
        return DirectoryFlag(newAttr);
    }
    DirectoryFlag& DirectoryFlag::operator-=(uint8 flags) {
        _attr &= ~(flags);
        return *this;
    }
    //Bitwise or
    DirectoryFlag DirectoryFlag::operator|(uint8 flags) {
        uint8 newAttr = _attr | flags;
        return DirectoryFlag(newAttr);
    }
    DirectoryFlag& DirectoryFlag::operator|=(uint8 flags) {
        _attr |= flags;
        return *this;
    }
    //Bitwise and
    DirectoryFlag DirectoryFlag::operator&(uint8 flags) {
        uint8 newAttr = _attr & flags;
        return DirectoryFlag(newAttr);
    }
    DirectoryFlag& DirectoryFlag::operator&=(uint8 flags) {
        _attr &= flags;
        return *this;
    }
    //Reverse flags
    DirectoryFlag DirectoryFlag::operator~() {
        return DirectoryFlag(_attr);
    }
    //Toggle flag bits
    DirectoryFlag& DirectoryFlag::operator^=(uint8 flags) {
        _attr ^= flags;
        return *this;
    }
    //Judge whether flags are contained
    bool DirectoryFlag::contains(uint8 flags) {
        return (_attr & flags) == flags;
    }
    +

    之后就可以根据上述表格完成DirEntry类的定义和实现了。需要注意的是，由于要从跟日期和时间有关的域中解析出对应的年月日或是时分秒仍然需要一步操作，所以我将条目中用到的时间和日期又额外包装成FATDate和FATTime放在fatdt.h中，并在这两个类中提供解析出年月日和时分秒的接口，在DirEntry的接口中不在返回裸的数值，而是将其转换为这两个类的实例进行返回。

    +

    我所实现的fatdt.h文件内容如下：

    +
    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
    #include "types.h"

    #ifndef _FAT_DT_H_
    #define _FAT_DT_H_

    class FATDate {
        private:
            uint16 _date;
        public:
            FATDate(uint16 date);
        public:
            uint16 year();
            void setYear(uint16 year);
            uint16 month();
            void setMonth(uint16 month);
            uint16 day();
            void setDay(uint16 day);
    };

    class FATTime {
        private:
            uint8 _timeTenth;
            uint16 _time;
        public:
            FATTime(uint8 timeTenth, uint16 time);
        public:
            uint16 hour();
            void setHour(uint16 hour);
            uint16 minute();
            void setMinute(uint16 minute);
            uint16 second();
            void setSecond(uint16 second);
            uint16 millisecond();
            void setMillisecond(uint16 millisecond);
    };

    #endif
    +

    关于具体函数的实现，就留给读者自己完成。

    +
    +

    综上，可以完成fatdir.h文件如下：

    +
    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
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    #include "types.h"
    #include "fatdt.h"

    #ifndef _FAT_DIR_H_
    #define _FAT_DIR_H_

    #define LAST_LONG_ENTRY 0x40

    class DirectoryFlag;
    class DirEntry;

    class DirectoryFlag {
        public:
            enum ATTRIBUTES {
                READ_ONLY   = 1,
                HIDDEN      = 1 << 1,
                SYSTEM      = 1 << 2,
                VOLUME_ID   = 1 << 3,
                DIRECTORY   = 1 << 4,
                ARCHIVE     = 1 << 5
            };
        private:
            uint8 _attr;
        public:
            DirectoryFlag();
            DirectoryFlag(uint8 flags);
        public:
            DirectoryFlag& operator=(uint8 flags);
            DirectoryFlag& operator=(const DirectoryFlag& other);
            //Judge whether two flags are equal
            bool operator==(uint8 flags);
            //Combine two flags
            DirectoryFlag operator+(uint8 flags);
            DirectoryFlag& operator+=(uint8 flags);
            //Remove flags
            DirectoryFlag operator-(uint8 flags);
            DirectoryFlag& operator-=(uint8 flags);
            //Bitwise or
            DirectoryFlag operator|(uint8 flags);
            DirectoryFlag& operator|=(uint8 flags);
            //Bitwise and
            DirectoryFlag operator&(uint8 flags);
            DirectoryFlag& operator&=(uint8 flags);
            //Reverse flags
            DirectoryFlag operator~();
            //Toggle flag bits
            DirectoryFlag& operator^=(uint8 flags);
            //Judge whether flags are contained
            bool contains(uint8 flags);
    };

    class DirEntry {
        private:
            byte _data[32];
        public:
            bool isEmpty();
            bool isSFNEntry();
            bool isLFNEntry();
            bool isLastInSet();
            DirectoryFlag attributes();
            FATTime createTime();
            FATDate createDate();
            FATDate lastAccessedDate();
            FATTime lastModifiedTime();
            FATDate lastModifiedDate();
            uint32 firstCluster();
            uint32 fileSize();
            uint32 lfnIndex();
            void parseASCIIFileName(byte* dst);
            uint32 checkSum();
    };

    #endif
    +

    完整的fatdir.cpp则实现如下：

    +
    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
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    137
    138
    139
    140
    141
    142
    143
    144
    145
    146
    147
    148
    149
    150
    151
    152
    153
    154
    155
    156
    157
    158
    159
    160
    161
    162
    163
    164
    165
    166
    167
    168
    169
    170
    171
    172
    173
    174
    175
    176
    177
    178
    179
    180
    181
    182
    183
    184
    185
    186
    187
    188
    189
    190
    191
    192
    193
    194
    195
    196
    197
    198
    199
    200
    201
    202
    203
    204
    205
    206
    207
    208
    209
    210
    211
    212
    213
    214
    215
    216
    217
    218
    219
    220
    221
    222
    223
    224
    225
    226
    227
    228
    229
    230
    231
    232
    233
    234
    235
    236
    237
    238
    239
    240
    241
    242
    243
    244
    245
    246
    247
    248
    249
    250
    251
    252
    253
    254
    255
    256
    257
    258
    259
    260
    261
    262
    263
    264
    265
    266
    267
    268
    269
    270
    271
    272
    273
    274
    275
    276
    277
    278
    279
    280
    281
    #include "fatdir.h"

    DirectoryFlag::DirectoryFlag() {
        _attr = 0;
    }
    DirectoryFlag::DirectoryFlag(uint8 flags) {
        _attr = flags;
    }
    DirectoryFlag& DirectoryFlag::operator=(uint8 flags) {
        _attr = flags;
        return *this;
    }
    DirectoryFlag& DirectoryFlag::operator=(const DirectoryFlag& other) {
        _attr = other._attr;
        return *this;
    }
    //Judge whether two flags are equal
    bool DirectoryFlag::operator==(uint8 flags) {
        return _attr == flags;
    }
    //Combine two flags
    DirectoryFlag DirectoryFlag::operator+(uint8 flags) {
        uint8 newAttr = _attr | flags;
        return DirectoryFlag(newAttr);
    }
    DirectoryFlag& DirectoryFlag::operator+=(uint8 flags) {
        _attr |= flags;
        return *this;
    }
    //Remove flags
    DirectoryFlag DirectoryFlag::operator-(uint8 flags) {
        uint8 newAttr = _attr & ~(flags);
        return DirectoryFlag(newAttr);
    }
    DirectoryFlag& DirectoryFlag::operator-=(uint8 flags) {
        _attr &= ~(flags);
        return *this;
    }
    //Bitwise or
    DirectoryFlag DirectoryFlag::operator|(uint8 flags) {
        uint8 newAttr = _attr | flags;
        return DirectoryFlag(newAttr);
    }
    DirectoryFlag& DirectoryFlag::operator|=(uint8 flags) {
        _attr |= flags;
        return *this;
    }
    //Bitwise and
    DirectoryFlag DirectoryFlag::operator&(uint8 flags) {
        uint8 newAttr = _attr & flags;
        return DirectoryFlag(newAttr);
    }
    DirectoryFlag& DirectoryFlag::operator&=(uint8 flags) {
        _attr &= flags;
        return *this;
    }
    //Reverse flags
    DirectoryFlag DirectoryFlag::operator~() {
        return DirectoryFlag(_attr);
    }
    //Toggle flag bits
    DirectoryFlag& DirectoryFlag::operator^=(uint8 flags) {
        _attr ^= flags;
        return *this;
    }
    //Judge whether flags are contained
    bool DirectoryFlag::contains(uint8 flags) {
        return (_attr & flags) == flags;
    }

    //Check whether the entry is empty
    //@return {bool} : True for the entry IS empty while False for the opposite
    bool DirEntry::isEmpty() {
        //According to Microsoft FAT specification:
        //DIR_Name[0] = 0xE5 indicates the directory entry is free
        //DIR_Name[0] = 0x00 indicates the directory entry and all directory entries following the current free entry are free
        //Since 0xE5 would never appear in LFN entries, therefore 0xE5 and 0x00 are unique signatures for empty entries
        return _data[0] == 0xE5 || _data[0] == 0x00;
    }

    //Check whether the entry is a short filename entry
    //@return {bool} : True for the entry IS a short filename entry while False for the opposite
    bool DirEntry::isSFNEntry() {
        //According to Microsoft FAT specification:
        //DIR_Attr field indicates whether the entry is a long filename entry
        //READ_ONLY | HIDDEN | SYSTEM | VOLUME_ID indicates a long filename entry
        return !attributes().contains(
            DirectoryFlag::READ_ONLY | 
            DirectoryFlag::HIDDEN | 
            DirectoryFlag::SYSTEM | 
            DirectoryFlag::VOLUME_ID
        );
    }

    //Check whether the entry is a long filename entry
    //@return {bool} : True for the entry IS a long filename entry while False for the opposite
    bool DirEntry::isLFNEntry() {
        //According to Microsoft FAT specification:
        //DIR_Attr field indicates whether the entry is a long filename entry
        //READ_ONLY | HIDDEN | SYSTEM | VOLUME_ID indicates a long filename entry
        return attributes().contains(
            DirectoryFlag::READ_ONLY |
            DirectoryFlag::HIDDEN |
            DirectoryFlag::SYSTEM |
            DirectoryFlag::VOLUME_ID
        );
    }

    //Check whether the entry is the last member in the lfn entry set
    //@return {bool} : True for the entry IS the last member in the set while False for the opposite
    bool DirEntry::isLastInSet() {
        //According to Microsoft FAT specification:
        //The last long directory name entry in the set is masked with 0x40 in the LDIR_Ord field
        return (_data[0] & LAST_LONG_ENTRY) != 0;
    }

    //Return the DIR_Attr field in the entry
    //@return {DirectoryFlag} : The attributes of the entry in DirectoryFlag format
    DirectoryFlag DirEntry::attributes() {
        //According to Microsoft FAT specification:
        //DIR_Attr field has an offset of 11 and size of 1 byte
        return DirectoryFlag(_data[11]);
    }

    //Return the creation time of the file/directory in FATTime format
    //It should be noted that only SFN entries hold this field
    //@return {FATTime} : The creation time, including hour, minute, second and millisecond
    FATTime DirEntry::createTime() {
        //According to Microsoft FAT specification:
        //DIR_CrtTimeTenth has an offset of 13 and size of 1 byte
        //DIR_CrtTime has an offset of 14 and size of 2 bytes
        return FATTime(_data[13], *(uint16*)(&_data[14]));
    }

    //Return the creation date of the file/directory in FATDate format
    //It should be noted that only SFN entries hold this field
    //@return {FATDate} : The creation date, including year, month and day
    FATDate DirEntry::createDate() {
        //According to Microsoft FAT specification
        //DIR_CrtDate has an offset of 16 and size of 2 bytes
        return FATDate(*(uint16*)(&_data[16]));
    }

    //Return the last accessed date of the file/directory in FATDate format
    //It should be noted that only SFN entries hold this field
    //@return {FATDate} : The last accessed date, including year, month and day
    FATDate DirEntry::lastAccessedDate() {
        //According to Microsoft FAT specification
        //DIR_LstAccDate has an offset of 18 and size of 2 bytes
        return FATDate(*(uint16*)(&_data[18]));
    }

    //Return the last modification time of the file/directory in FATTime format
    //It should be noted that only SFN entries hold this field
    //@return {FATTime} : The last modification time, including hour, minute, second and millisecond
    FATTime DirEntry::lastModifiedTime() {
        //According to Microsoft FAT specification
        //Last modification time is stored in DIR_WrtTime field
        //DIR_WrtTime has an offset of 22 and size of 2 bytes
        //It should be noted that last modification time does not provide granularity under 2 seconds
        //More specifically, there is no timetenth field for last modification time
        return FATTime(0, *(uint16*)(&_data[22]));
    }

    //Return the last modification date of the file/directory in FATDate format
    //It should be noted that only SFN entries hold this field
    //@return {FATDate} : The last modification date, including year, month and day
    FATDate DirEntry::lastModifiedDate() {
        //According to Microsoft FAT specification
        //Last modification date is stored in DIR_WrtDate field
        //DIR_WrtDate has an offset of 24 and size of 2 bytes
        return FATDate(*(uint16*)(&_data[24]));
    }

    //Return the first cluster of the file/directory
    //It should be noted that only SFN entries hold this field
    //@return {uint32} : The first cluster of the file/directory
    uint32 DirEntry::firstCluster() {
        //According to Microsoft FAT specification
        //first cluster is defined in DIR_FstClusHI and DIR_FstClusLO
        //This function simply concatenates the high and low bits and returns
        uint16 frstClusterHI = *(uint16*)(&_data[20]);
        uint16 frstClusterLO = *(uint16*)(&_data[26]);
        uint32 frstCluster = ((uint32)frstClusterHI << 16) | frstClusterLO;
        return frstCluster;
    }

    //Return the size of the file/directory
    //It should be noted that only SFN entries hold this field
    //@return {uint32} : The size of the file/directory in bytes
    uint32 DirEntry::fileSize() {
        //According to Microsoft FAT specification
        //The DIR_FileSize field holds the 32-bit quantity containing size in bytes of file/directory described by this entry
        //DIR_FileSize field has an offset of 28 and size of 4 bytes
        return *(uint32*)(&_data[28]);
    }

    //Return the order of the entry in the set of LFN entries
    //It should be noted that only LFN entries hold this field
    //@return {uint32} : The order of the entry
    uint32 DirEntry::lfnIndex() {
        //According to Microsoft FAT specification:
        //The order of the entry is defined in LDIR_Ord field
        //LDIR_Ord field has an offset of 0 and size of 1 byte
        //
        //It should also be noted that the field can be masked with 0x40 if it's the last entry in the set
        //
        //Therefore, bit 6 should be masked out during returing
        //
        //A pretty safe way is to return only the low 6 bits of this field
        //since the long filename would not exceed the 255 characters limit,
        //which equals to 255/13 = 20 = 0x14 entries, of which bit 5 is not even used for maximum length filename
        return _data[0] & 0x3F;
    }

    //Extract every first bit out of two bits of the filename
    //transforming the filename into ASCII format and copy the transformed filename to dst
    //It should be noted that this function BEHAVE DIFFERENTLY in SFN and LFN entries
    //- in LFN entries: the filename is transformed into ASCII and copied to param dst
    //- in SFN entries: the short filename is copied to param dst
    //@param {byte*} dst : Destination memory where the filename will be copied to
    void DirEntry::parseASCIIFileName(byte* dst) {
        //According to Microsoft FAT specification:
        if(isLFNEntry()) {
            //The filename in LFN entry is stored in three parts
            //LDIR_Name1 has an offset of 1 and size of 10 bytes
            //LDIR_Name2 has an offset of 14 and size of 12 bytes
            //LDIR_Name3 has an offset of 28 and size of 4 bytes
            //The file name is stored in UNICODE which is 16-bit per character
            //
            //Since only English words is used in the implementation
            //it's okay to extract every frist bit out of two to transform UNICODE into ASCII
            for(int i = 0; i < 5; i++) {
                dst[i] = _data[1 + 2 * i];
            }
            for(int i = 0; i < 6; i++) {
                dst[5 + i] = _data[14 + 2 * i];
            }
            for(int i = 0; i < 2; i++) {
                dst[11 + i] = _data[28 + 2 * i];
            }
        }
        else {
            //The filename in SFN entry is sotred in DIR_Name field
            //which as an offset of 0 and size of 11 bytes
            for(int i = 0; i < 11; i++) {
                dst[i] = _data[i];
            }
        }
    }

    //Calculate/Return the checksum of the entry
    //It should be noted that this function BEHAVE DIFFERENTLY in SFN and LFN entries
    //@return {uint32} : Calculate checksum out of filename in SFN entries
    //@return {uint32} : Return checksum in LFN entries
    uint32 DirEntry::checkSum() {
        if(isSFNEntry()) {
            //ChkSum()
            //Returns an unsigned byte checksum computed on an unsigned byte
            //array. The array must be 11 bytes long and is assumed to contain
            //a name stored in the format of a MS-DOS directory entry

            //The following method is copied from Microsoft FAT specification
            //page 32, chapter 7.2 Checksum generation
            byte* pName = &_data[0];
            uint16 nameLen;
            uint8 sum;
            sum = 0;
            for(nameLen = 11; nameLen != 0; nameLen--) {
                //NOTE: The operation is an unsigned char rotate right
                sum = ((sum & 1) ? 0x80 : 0) + (sum >> 1) + *pName++;
            }
            return sum;
        }
        else {
            //According to Microsoft FAT specification:
            //The checksum in LFN entries is stored in LDIR_Chksum field
            //which has an offset of 13 and size of 1 byte
            return _data[13];
        }
    }
    +

    抽象MBR结构

    +

    上一小节中，我们实现了FAT文件系统的抽象，为从文件系统中读取内核文件奠定了基础。对于一个仅有一个分区的硬盘而言，如果其文件系统恰是FAT格式，那么就可以使用我们抽象出的接口访问其中的文件。

    +

    但现如今磁盘中只有一个分区的电脑少之又少，如果磁盘中有多个FAT格式的分区，那么加载程序应该去哪个分区寻找内核文件，又该如何定位到对应分区的位置呢？

    +

    这些就要依赖于存储在MBR中的数据了。在第二章：计算机是如何启动的一节中提到，MBR在447~510这64个字节中存储了分区表信息，包括了分区的引导标志、起始磁道、起始扇区、起始柱面等信息。

    +

    注：实验中使用的是MBR分区表
    +在实验中使用的是MBR分区表，而不是GPT分区表，所以通过MBR来解析分区信息。
    +在MBR分区表下，最多只能存在四个主分区，这是由MBR存储分区表区域的空间限制所导致的，更多的分区则需要使用逻辑分区来表示，关于逻辑分区的内容与本次实验无关，故此处不进行介绍。

    +
    +

    通过这些特殊的信息，加载程序就可以判断哪个分区是活动的，以及这个分区在磁盘上的位置，以及分区上文件系统的类型。在确定了这些信息之后，加载程序就可以使用上一节中关于文件系统的接口来读取和加载内核文件了。

    +

    在经历了对文件系统的抽象之后，此时大家应该很快就能想到，为了能够方便地解析MBR中分区表的数据，可以对MBR的结构进行抽象。

    +

    MBR结构

    +

    参考资料：MBR结构
    +关于MBR结构的详细信息，此文中参考了 Wikipedia中关于MBR的页面 ，其中，实验采用了Classical generic MBR的格式对MBR结构进行解析。

    +
    +

    在最一般的MBR结构中，其包含了三个主要的部分：

    + +

    它们的地址和大小如下：

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    内容起始地址大小
    启动代码0x0000446B
    分区条目1
    Partition entry №1    		0x01BE16B
    分区条目2
    Partition entry №2    		0x01CE16B
    分区条目3
    Partition entry №3    		0x01DE16B
    分区条目4
    Partition entry №4    		0x01EE16B
    启动签名0x01FE2B
    +

    Partition Entry结构

    +

    同时，每个分区条目 (Partition entry) 又具有如下的结构：

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    偏移大小描述
    0x001描述分区的状态
    0x80用来表示活动分区
    0x00表示非活动分区
    其他值均为无效值
    0x013分区首扇区的CHS表示
    0x041分区的类型
    0x053分区末扇区的CHS表示
    0x084分区首扇区的LBA扇区号
    0x0C4分区总扇区数
    +

    其中，根据 Wikipedia上关于分区类型的页面 中的描述，实验中将会用到的分区类型以及它们的值为：

    + + + + + + + + + + + + + + + + + + + + + + + + + +
    类型值
    FAT120x01
    FAT160x04
    FAT32(CHS)0x0B
    FAT32(LBA)0x0C
    +

    同时，扇区号的CHS表示又具有如下的结构：

    + + + + + + + + + + + + + + + + + + + + + + + + + +
    偏移大小描述
    0x001磁头号 (head)
    0x011由两部分组成：
    高2位为柱面 (cylinder) 第8-9位
    低6位为扇区号 (sector) 第0-5位
    0x021柱面 (cylinder) 第0-7位
    +

    可见，对于一个分区条目而言，其主要的作用就是判断分区是否存在、判断分区的状态（是否是活动分区）、标记分区的文件系统类型以及获取分区的首扇区号和扇区数，因此其接口就主要围绕这些方面进行设计：

    +
    1
    2
    3
    4
    5
    public:
        bool isPresent();
        bool isActive();
        uint32 firstSectorLBA();
        uint32 sectorNum();
    +

    抽象Partition Entry

    +

    明确了分区条目的结构和需要提供的接口，可以迅速将分区条目抽象为Partition类型如下：

    +
    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
    class Partition {
        public:
            enum Status {
                INACTIVE    = 0,
                ACTIVE      = 1 << 7
            };
            enum Type {
                EMPTY           = 0,
                FAT12           = 0x01,
                FAT16           = 0x04,
                FAT32_CHS       = 0x0B,
                FAT32_LBA       = 0x0C,
            };
        public:
            uint8 _status;          //Status for bootable
            CHSAddress _frstSecCHS;  //CHS address of first absolute sector in partition
            uint8 _type;              //Partition type
            CHSAddress _lastSecCHS;  //CHS address of last absolute sector in partition
            byte _frstSecLBA[4];     //LBA address of first absolute sector in partition
            byte _numSec[4];         //Number of sector in the partition
        public:
            bool isPresent();
            bool isActive();
            uint32 firstSectorLBA();
            uint32 sectorNum();
    };
    +

    上述接口则均实现在partition.cpp文件中：

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    #include "partition.h"

    bool Partition::isPresent() {
        return sectorNum() != 0;
    }

    bool Partition::isActive() {
        return _status == ACTIVE;
    }

    uint32 Partition::firstSectorLBA() {
        return *(uint32*)_frstSecLBA;
    }

    uint32 Partition::sectorNum() {
        return *(uint32*)_numSec;
    }
    +

    同时，在分区条目的结构中涉及到的CHS扇区号由上文中提到的CHS结构抽象为CHSAddress类型，其只需要提供从3字节长度的数据中提取柱面、磁头和扇区号的接口：

    +
    1
    2
    3
    4
    5
    6
    7
    8
    class CHSAddress {
        public:
            byte address[3];
        public:
            uint32 cylinder();
            uint32 head();
            uint32 sector();
    };
    +

    注：
    +由于在实验中实际上并不会通过CHS的地址来计算扇区号，因此在实验中并没有对这三个接口进行具体的实现，这部分内容就留给读者完成。

    +
    +

    抽象MBR

    +

    实现了对分区条目的抽象之后，对MBR结构的抽象就易如反掌了，因为其实际上就是由一段长度为446的字节数组 (Bootstrap code) 、四个分区条目类型的对象 (Partition table) 以及一个两字节的数组 (Boot signature) 组成的：

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    //mbr.h

    #include "types.h"
    #include "partition.h"

    #ifndef _MBR_H_
    #define _MBR_H_

    class MBR {
        public:
            byte bootstrap[446];    //Bootstrap code
            Partition partition_1;  //Partition entry #1
            Partition partition_2;  //Partition entry #2
            Partition partition_3;  //Partition entry #3
            Partition partition_4;  //Partition entry #4
            byte signature[2];      //Bootable signature
    };

    #endif
    +

    由于Partition类型的对象已经提供了足够使用的接口，因此MBR并不需要再设计额外的接口，而只需要将四个Partition的变量暴露给程序即可。如果程序想要从MBR中获得一个分区是否是活动的，以及其起始的LBA扇区号，其可以进行如下的操作：

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    //Assume there is a MBR typed variable mbr
    //假设已经有一个MBR类型的对象mbr
    Partition p = mbr.partition_1;
    //Check the status of the partition
    //检查分区是否是活动的
    if(p.isActive()){
        //Do something if the partition is active
        //如果分区是活动的，则会执行的代码
    }
    //Get the LBA of first sector
    //获取分区第一个扇区的LBA扇区号
    lba = p.firstSectorLBA();
    +

    抽象页表

    +

    实现了MBR和文件系统的抽象就意味着现在我们已经可以从硬盘中找到需要的内核文件了，并且借助硬盘读取的接口将内核的文件从硬盘中读取到内存。下一步就是将内核加载到正确的地址空间中，完成加载内核的全部步骤。但是在开始加载内核之前，需要先了解虚拟内存的概念以及分页机制的原理，并且实现对分页要用到的数据结构进行抽象后才能正确地对内核进行加载。

    +

    简述虚拟内存与分页机制

    +

    参考资料
    +如果想要了解关于内存管理策略以及虚拟内存的全部内容，可以阅读课本《操作系统概念》中第三部分关于内存管理的内容，我强烈建议先完成这部分的阅读再继续后面的实验。
    +当然，在接下来的相当一部分篇幅中，我也会用我自己的理解介绍什么是虚拟内存，以及分页机制的最基本概念。但这些远不如书本全面、权威，因此再次建议大家先对课本进行一次略读后再继续后面的实验内容。

    +
    +

    既然要介绍虚拟内存和分页机制，自然就要从它们出现的原因谈起，而这就绕不开 “程序是如何运行起来的” 这个话题。

    +

    在学完了『操作系统原理』这门课后，想必已经对程序的运行有了一个大致的认识，知道了程序运行的基础是CPU对机器指令的执行，而CPU执行机器指令由是由数个流水级逐步完成的，不考虑分支预测等等复杂的实现，CPU对指令的执行可以抽象为以下的步骤：

    +
      +
    1. 存储指令地址的存储器（可以视作PC）提供了一个地址信号输入存储指令的存储器（在这里就是内存了）
      2. +
    2. 内存根据输入的地址信号在下一个时钟沿输出对应地址空间上存储的指令
      3. +
    3. 其他流水级完成指令的解析等，同时指令地址完成一次自增
      4. +
    +

    可见，想让程序运行起来，关键就是两步：

    +
      +
    1. 把指令存到内存中
      2. +
    2. 把指令的地址放置到存储指令地址的存储器（PC）中
      3. +
    +

    这样，在下一个时钟周期到来的时候，CPU就会从想要执行的指令处开始执行了。

    +

    把指令的地址放置到PC中就十分简单了，在汇编中常见的跳转指令都可以完成这一操作，在硬件上的实现想必大家也是历历在目的（小声），那剩下还要解决的就是把指令存到内存中这个问题啦。

    +

    但偏偏就是把指令存到内存中这么一个看起来很简单的操作，背后却暗藏了各种难题，为了这么一个操作，曾经的工程师们也可谓是八仙过海，各显神通。

    +

    还记得我们在第二部分：从代码到可执行文件一节中提到的程序的链接步骤中提到，在链接时需要指定程序起始的地址，这个地址关系到了整个程序所有代码段中使用到的绝对地址的计算，这就为程序的加载带来了一个大难题：

    +

    如果我不知道程序要加载到哪里，那我应当如何指定程序起始的地址？
    +如果强行提前指定了程序的起始地址，那个地址被其他的程序占用了又该怎么办？

    +
    +

    于是，曾经伟大的工程师们就提出了一个概念：让程序视角下的地址和它真正运行着的地址分开。通俗点解释，就是令程序在执行的时候中，其指令中的各种地址都视为程序视角下的地址，通过一些手段，让这个地址和真正访问内存的地址不是同一个地址，但又存在着一定的映射关系：

    +

    AccessAddress=f(ProgramAddress)AccessAddress = f(ProgramAddress) +

    +

    结合才学没多久的计算机组成原理课程的知识，可以大致理解为，在从指令中分离出地址后并不是直接送入内存，而是经过一个特殊的地址变换部件 (这也就是常说的MMU) 之后才会送入内存。

    +

    图 1

    +

    什么是程序视角下的地址：

    +

    就像上图，当程序在运行的时候，CPU会根据指令生成出一些地址的值，例如mov eax, dword [ebx]会从内存中加载4字节数据，其产生的地址是ebx中存储的值；或是jmp 0x7E00会跳转到0x7E00处执行，CPU会产生0x7E00这个地址送入指令地址寄存器。

    +

    然而，CPU所不断地产生出的地址的值，还需要经过地址变换部件才能成为有意义的地址。对于CPU而言，它并不知道MMU的存在，它只知道指令生成了一些地址，而且在运行的过程中这些地址确实产生了正确的效果，看起来就像是程序真的就放在这个地址上运行一样，而不知道这些地址实际上是由于MMU的地址变换作用才产生了正确的效果，所以这实际上这些未经变换都可以被称作是CPU“假想”的地址，也就是常说的虚拟地址，我个人喜欢将它们称为是程序视角下的地址，我认为这样说会更形象、更易于理解。

    +

    由于程序的视角其实通俗理解就是CPU的视角，所以在程序执行过程中由CPU生成的地址，其实就是程序视角下的地址。

    +

    这些地址是虚拟的，是假定的，因为它们并不能代表程序在内存中存放的地址，这一点很重要。

    +
    +

    陷阱：程序某个部分在内存中的地址≠程序视角中这个部分的地址
    +要理解后面的分页制度，就一定要有程序视角的地址是“假想”的地址，是程序所认为的它在内存中的位置的概念。
    +在出现了地址变换部件这个概念之后，程序在运行的时候由CPU生成的所有地址都不再一定是CPU想要从内存中获取的数据的地址，而是要经由一次MMU的映射才能获得程序想从内存中获取的数据的地址。

    +
    +

    这样，即便程序都以0x0为起始地址，也可以通过不同的地址变换方式来达到将程序存储在内存中不同位置的效果。

    + +

    但是摆在工程师面前的，还有更多的问题：

    +

    如何从空闲的空间中选择合适的位置存储需要加载的程序？

    +
    +

    在操作系统运行的过程中，会不断有程序需要被加载到内存运行，同时也会不断地有程序结束运行。结束运行的程序可以释放出它本身占用的空间，需要加载运行的程序则需要申请能够存放其自身的空间。如此往复的过程中，不断被申请然后被释放的程序所占用的内存空间会让内存的地址空间中出现一个个的空洞 (Hole)，原先连续的大片空闲区域就这样被分割成了不连续的许多小的空闲的内存片段：

    + +

    这听起来就不是什么好事，事实上也确实是如此，当操作系统要加载一个新的程序进入内存的时候，它几乎一定面对的是一个“满目疮痍”的内存空间，而如何从无数的空洞中选择合适的那个来存放程序，也就成了一个难题。过去的工程师提出了三种解决方案：

    + + +

    碎片：

    +

    在上面的描述的三种为程序的分配内存的方式中可以看出并不是每一次都能够为程序分配恰到好处的空间，往往一个新程序的加载会导致内存中出现小的空洞，这些空洞小到几乎不足以放下任何其他的程序，这就意味着这部分内存直到程序运行完毕被释放之前都不能够被操作系统用来为其他程序分配，这些实际上被浪费掉的内存空间就是碎片。

    +

    碎片又分为外部碎片和内部碎片，前述的这种在为程序分配的空间以外的浪费空间叫做外部碎片，而如果操作系统为一个程序分配了多余它实际要使用的内存空间，那么其内部被浪费掉的空间就叫做内部碎片，这种类型的碎片将会在后面介绍分页机制时看到。

    +

    碎片对于内存空间的利用而言是致命的，试想一个充满了碎片的内存，明明其空闲的空间足够大，但是由于全部都是由碎片组成，而不能放入任何一个程序。

    +
    +

    然而，上面的三种分配方式都仍然是将一个程序视为一个整体进行加载的，多少有点偏执了。

    +

    假设内存中有 44 个大小为 16KiB16KiB 大小的空洞，需要加载一个大小为 60KiB60KiB 大小的程序，此时不论采用上述哪一种分配方式，都无法找到任何一个合适的空洞来装载新的程序。如果此时摒弃非要把一个程序连续装入内存的落后思想，而是想办法把程序剁成四块，分别为 16KiB16KiB 、 16KiB16KiB 、 16KiB16KiB 和 12KiB12KiB ，然后装入四个空洞中，不就成了吗？

    + +

    聪明的工程师自然也想到了，所以分页的概念也就应运而生。

    +

    为了方便操作系统进行管理，工程师将内存和程序都按照一个相同的大小进行分割，例如常见的 4KiB4KiB，这个固定大小的空间就叫做页，将内存和程序分割的过程也就叫做分页。

    +

    对于内存而言，剩余不足一页的空间会被舍弃；对于程序而言，不足一页的部分也会分配一个完整的页，这时页中没有被使用的部分就是内部碎片，例如如果程序的大小为 4KiB+1B4KiB + 1B，而页的大小为 4KiB4KiB，则程序会占用两个页，即使第二个页中只有一个字节是真正被使用的，这就产生了 4095B4095B 的内部碎片。

    +

    陷阱：对程序分页实质上是对程序地址空间进行分页
    +对程序分页是指的对程序视角下的地址空间进行分页，而不是对程序实际在内存中占用的地址空间进行分页，并且这之中还有一个先后的关系，程序只有先对它所用到的地址空间进行分页，才能对应地放入到内存中分好的页里。

    +
    +

    物理页和虚拟页：
    +在后文中，物理页就将指代内存中的页，而虚拟页就将指代程序的虚拟地址空间中的页。

    +
    +

    在内存进行了分页之后，往后内存空间的分配和释放都会以一页为最小单位，因此当需要加载新的程序进入内存时，如果内存中空闲的页不少于程序运行所需要的页，则为程序分配其所需要的数量的页，并且建立一个从程序视角下的页到实际内存中的页的映射关系

    + +

    有了这样的映射关系，操作系统就可以对应着将程序的内容装载进内存，至于在程序视角下的地址空间内那些空间需要写入内存、怎样写入内存等等将会留到下一小节介绍。

    +

    但是这样复杂的映射关系，CPU是如何记住的呢？

    +

    这就要提到本章节的主角页表了。为了能够让MMU知道程序视角下的页与内存中页的映射关系，早期的工程师创造了一个类似FAT表的表结构，其中每个程序视角下的页都可以对应到一个表项，而每个表项中的内容都对应到一个内存中的页，这个对应关系使用内存页的首字节地址表示。

    + +

    不过CPU产生的地址肯定不会是页的大小的整数倍，而是可能对应着一个页内的任何一个字节，此时如果只有页的映射关系是否有些不够了呢？

    +

    自然不是的。由于页在映射的时候是将一个页视为一个整体进行映射，所以同一个内容在虚拟页和物理页中的偏移量是相同的，在对CPU生成的地址进行变换的时候，只需要将页的地址和偏移量分离开来，通过页表得到物理页的地址以后，再将其作为基址叠加上原先分离出的偏移量，就可以得到映射后的地址了。

    +

    PageOffset=VirtualAddress % PageSizeVirtualPageAddress=VirtualAddress−PageOffsetPhysicalPageAddress=f(VirtualPageAddress)PhysicalAddress=PhysicalPageAddress+PageOffset\begin{align} +&PageOffset = VirtualAddress \ \% \ PageSize \nonumber \\ +&VirtualPageAddress = VirtualAddress - PageOffset \nonumber \\ +&PhysicalPageAddress = f(VirtualPageAddress) \nonumber \\ +&PhysicalAddress = PhysicalPageAddress + PageOffset \nonumber +\end{align} +

    +

    不过，只是得到虚拟页的首字节地址还不够，既然要在页表中寻找对应关系，就需要知道虚拟页对应的下标，也就是虚拟页在所有页中的序号。由于页的大小都是 2n2^n 形式，所以第 kk 个虚拟页的地址有如下关系：

    +

    VirtualPageAddressk=k×2n=k<<n\begin{align} +VirtualPageAddress_k &= k \times 2^n \nonumber \\ +&= k << n \nonumber \\ +\end{align} +

    +

    所以对于一个虚拟页，其在页表中的下标就可以通过虚拟页的地址移位得到。对于大小为 2n2^n 的页，一个虚拟页对应的下标为

    +

    VirtualPageIndex=VirtualPageAddress>>nVirtualPageIndex = VirtualPageAddress >> n +

    +

    代入上式可得

    +

    VirtualPageIndex=VirtualPageAddress>>n=(VirtualAddress−PageOffset)>>n=(VirtualAddress−VirtualAddress % 2n)>>n=(VirtualAddress−(VirtualAddress−floor(VirtualAddress÷2n)×2n))>>n=(VirtualAddress−(VirtualAddress−(VirtualAddress>>n)<<n))>>n=VirtualAddress>>n<<n>>n=VirtualAddress>>n\begin{align} +VirtualPageIndex &= VirtualPageAddress >> n \nonumber \\ +&= (VirtualAddress - PageOffset) >> n \nonumber \\ +&= (VirtualAddress - VirtualAddress \ \% \ 2^n) >> n \nonumber \\ +&= (VirtualAddress - (VirtualAddress - floor(VirtualAddress \div 2^n) \times 2^n)) >> n \nonumber \\ +&= (VirtualAddress - (VirtualAddress - (VirtualAddress >> n) << n)) >> n \nonumber \\ +&= VirtualAddress >> n << n >> n \nonumber \\ +&= VirtualAddress >> n \nonumber +\end{align} +

    +

    以 4KiB4KiB 大小的页为例，对于虚拟地址0xC00002a0，其高20位0xC0000代表这个地址所在的页的序号，而低12位0x2a0其实是代表着这个地址在页内部的偏移量。也即在程序的虚拟地址中，0xC00002a0地址位于第0xC0000页中第0x2a0个字节处。访问页表中下标为0xC0000的项，得到虚拟页对应的物理地址，例如0x20000000，再将物理地址和偏移量合并，得到映射后的物理地址0x200002a0。

    + +

    不过，如果按照这样的方式映射，对于一个32位的系统来说，每一个虚拟页都需要4个字节来存储其对应的物理页的地址，而32位的地址最多可以取到 4GiB4GiB 的地址范围，假设页的大小为 4KiB4KiB，以 S(x)S(x) 表示 x所占用的内存字节数，那么页表最多需要占用的内存计算如下：

    +

    S(PageTableEntry)=4S(VirtualAddressSpace)=232S(Page)=212(2),(3)⇒PageCnt=S(VirtualAddressSpace)÷S(Page)=220(4)⇒PageTableEntryCnt=PageCnt=220(1),(5)⇒S(PageTable)=S(PageTableEntry)×PageTableEntryCnt=222\begin{align} +&S(PageTableEntry) = 4 \\ +&S(VirtualAddressSpace) = 2^{32} \\ +&S(Page) = 2^{12} \\ +&(2), (3) \Rightarrow PageCnt = S(VirtualAddressSpace) \div S(Page) = 2^{20} \\ +&(4) \Rightarrow PageTableEntryCnt = PageCnt = 2^{20} \\ +&(1),(5) \Rightarrow S(PageTable) = S(PageTableEntry) \times PageTableEntryCnt = 2^{22} \nonumber +\end{align} +

    +

    也就是说，光是一个页表结构就要占用 4MiB4MiB 的内存空间，对于现在动辄 16GiB16GiB 的内存来说可能微不足道，但在曾今内存空间寸土寸金的时候，4MiB4MiB甚至足够跑起一个操作系统内核，这就显得页表有些过于臃肿了。于是，为了解决这个内存占用的问题，工程师们又提出了多级分页 (Multi-level paging) 的概念，其中在32位的操作系统中使用最多的是二级分页 (Two level paging)，而64位操作系统多使用四级分页或是更多级别的分页。尽管分页的级数会存在不同，但它们的原理都是相同的，而且都是为了解决一个问题：减少页表自身占用的存储空间。

    +

    以二级分页为例，实际上就是将原先页表的结构同样按照页划分为块，对于上面提到的32位架构中的页表结构可以被划分为 2102^{10} 个块，每一个划分出来的块都叫做一个一级页表 (Level 1 Page Table)。每个原先的页表项此时就可以像虚拟地址那样，表示成为一级页表的序号和页表内的偏移，不过此时的偏移就不是以字节为单位的偏移，而是以页表项元素大小（4字节）为单位的偏移。

    +

    对于一个原先页表项的序号 IndexIndex，它对应的一级页表的序号和页表内的偏移为：

    +

    EntryPerPage=PageSize÷PageTableEntrySize=212÷22=210Offset=Index % EntryPerPage=Index % 210PageIndex=floor(Index÷EntryPerPage)=floor(Index÷210)=Index>>10\begin{align} +&{ + \begin{align} + EntryPerPage &= PageSize \div PageTableEntrySize \nonumber \\ + &= 2^{12} \div 2^2 \nonumber \\ + &= 2^{10} \nonumber + \end{align} +} \nonumber \\ +&{ + \begin{align} + Offset &= Index \ \% \ EntryPerPage \nonumber \\ + &= Index \ \% \ 2^{10} \nonumber + \end{align} +} \nonumber \\ +&{ + \begin{align} + PageIndex &= floor(Index \div EntryPerPage) \nonumber \\ + &= floor(Index \div 2^{10}) \nonumber \\ + &= Index >> 10 \nonumber + \end{align} +} +\end{align} +

    +

    通俗而言，就是原先页表项的下标的高10位为这个页表项所在的一级页表的序号，低10位则为这个页表项在其所在的一级页表中的下标。例如页表中原先位于0x80200（0b1000_0000_0010_0000_0000）的页表项，可以认为是在第0x200（0b10_0000_0000）个一级页表中的第0x200个页表项。

    +

    在划分了一级页表之后，额外添加了一个页表，其中的每一项是32位的数值，指向这一项下标对应的一级页表所在的首字节的地址，这个页表就是二级页表 (Level 2 Page Table)。由于在32位架构的设备上最多有 2102^10 个一级页表，而一个一级页表对应的二级页表中的页表项大小为4字节，所以二级页表的大小为

    +

    210×4=212Byte=4KiB2^{10} \times 4 = 2^{12} Byte = 4KiB +

    +

    正好就是一个页的大小。

    +

    这样，当要将一个虚拟地址转换为物理地址时，需要

    +
      +
    1. 取低12位为页内偏移
      2. +
    2. 取中10位为一级页表内页表项的下标
      3. +
    3. 取高10位位二级页表内页表项的下标
      4. +
    4. 使用二级页表项的下标在二级页表中取得一级页表的地址
      5. +
    5. 使用一级页表项的下标和一级页表的地址取得虚拟地址对应的物理页的地址
      6. +
    6. 根据物理页的地址和页内偏移得到转换后的物理地址
      7. +
    + +

    乍一看，好像二级页表的出现是多此一举，本来可以直接用下标在页表里定位到页表项，从页表项直接取得物理页地址，现在还要多此一举，先从二级页表拿到一级页表的地址，然后才能拿到物理页地址。仔细一算的话，对于所有的虚拟页都进行映射的情况，二级分页甚至还要比不采用二级分页多出一个二级页表的大小，这哪里节约了页表占用的空间！

    +

    最初我也是同样对此感到十分地疑惑，一个不但增加了内存占用，复杂了流程还减慢了地址转换地速度的方案怎么就流传下来了呢？后来我意识到我忽略了一个很关键的细节：前文中讨论页表占用的内存是时始终是基于虚拟地址全部映射到物理地址这个前提进行的，然而事实上，大部分时候都不会需要将虚拟地址全部映射在内存中，甚至有时候内存根本就不够映射全部的虚拟地址！

    +

    虚拟地址不完全映射到内存就意味着页表中有空的页表项，对于没有二级分页的方案，由于整个页表都相当于一个巨大的数组结构，即使一个元素为空也不能舍弃它的空间，所以不论映射了多少虚拟页，页表占用的大小始终是固定的。然而对于二级分页的方案，由于二级页表记录的是一级页表的地址，这也就相当于拆散了原先巨大的页表，并且还使得拆分后得到的一级页表可以分散地存储在内存中。这样做还带来了一个巨大的好处，就是页表的内存不再需要一次性分配完毕，因为原先没有多级分页机制的时候，但凡需要页表，就需要一次性申请全部页表的空间，而现在即便一级和二级页表还是相当于数组结构，还是需要为每一个页表分配固定大小的内存，但是它们单个的体积从原先的 4MiB4MiB 降到了 4KiB4KiB，同时由于二级页表的存在，如果一整个一级页表内的表项全部为空，那么就可以不分配这个一级页表的空间，从而达到节省空间的目的。

    + +

    有了二级页表之后，现在摆在我们面前的只剩最后一个问题：

    +

    如果程序代码比内存还要大怎么办？

    +
    +

    早期的RAM相当金贵，远不及如今动辄16GiB、32GiB，能有个几兆几十兆都是奢侈。那如果一个程序就十分不巧，大小竟然比内存还大，那这个庞然大物该如何运行起来呢？

    +

    这就要提到一个叫做 程序运行的局部性原理 的概念，它是指程序在一段时间内程序的执行只限于程序的一部分，就以我们熟悉的冒泡排序算法为例吧：

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    for(int i = 0; i < n; i++) {
        for(int j = 0; j < n - i - 1; j++) {
            if(arr[j] < arr[j + 1]) {
                int temp = arr[j];
                arr[j] = arr[j + 1];
                arr[j + 1] = temp;
            }
        }
    }
    +

    即便程序的其余部分无比复杂，哪怕是3A巨制，但只要程序运行到这里，它在相当一段时间里只会在两个for循环里打转转，它访问的内存也只会局限在arr这个数组里，这就是程序的局部性，在这一段时间里程序所用到的空间就是程序所需要的工作集。

    +

    由于程序运行具有局部性的原理，所以不论程序占用的虚拟地址空间有多大，它在一个特定的时间长度内都不会访问全部的地址空间，这时只需要将其运行需要的部分加载到内存中，程序就可以正常地运行了。这就好比我们在玩Minecraft时候，往往我们的视野半径只有十几个区块，所以加载无尽的世界的所有区块（这显然是不可能的！）和只加载我们视野范围内的区块在我们看来效果是一样的（甚至肯定会流畅不止一点点），所以为了能让我们愉快的玩上游戏，游戏的设计者就不会让电脑加载视野范围外的区块，或者是限制加载视野范围外的区块，从而让我们体验不变的情况下让游戏能够正常地运行，电脑不至于直接冒烟。

    +

    抖动
    +即使程序运行具有局部性，但仍可能出现工作集比内存大小大的情况。
    +比如一个程序在某一时刻的工作集为10个页ABCDEFGHIJ，而内存只有9个页可供程序使用。
    +假设某一时刻程序加载了ABCDEFGHI页，当它需要J页的时候，其发现页并不在内存中，就会尝试从磁盘加载这个缺失的页进入内存。
    +而这个操作就会顶掉ABCDEFGHI中的一个页，很快，程序又会遇到被顶掉的页，其又会加载并顶掉另一个页。
    +这样的操作会如此不断重复，程序也就无法再正常地继续运行了，这就是抖动现象。

    +
    +

    抽象页表数据结构

    +

    现在，我们知道了什么是虚拟地址，什么是分页，什么是多级分页。在实验中我们要用到的就是上文中提到的二级分页机制，它用到了一级页表、二级页表和其中的页表项三个主要的数据结构，而一级页表和二级页表实质都是页表项的数组，没有本质上的差异，可以视为同一个数据结构，所以我们只需要实现页表和页表项的数据结构就足够使用了。

    +

    由于页表中需要用到页表项，所以我们首先来对页表项 (PageTableEntry) 进行抽象。

    +

    前文中提到，页表项中存储的是一级页表或是物理页的地址，其实这个描述不是十分准确。如前文所述，由于页的大小固定，并且都是 2n2^n 的大小，所以任何一个页的地址的低位其实都是相同的且都是0，这就意味着保留着些位是毫无意义的，例如，对于32位的架构而言，由于页的大小为 212B2^{12}B，所以任何一个页的地址低12位均为0。工程师显然也发现了这一点，所以它们决定利用这12个无用的位来存储更多的信息，包括页的属性、权限等。

    +

    根据 OSDevWiki上关于页表项结构的描述，页表项 (Page Table Entry) 的结构如下：

    + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    简写全称位描述
    PPresent[0]页表项存在位
    0：不存在
    1：存在
    R/WRead/Write[1]写权限位
    0：不可写
    1：可写
    U/SUser/Supervisor[2]访问权限位
    0：用户级程序不可访问
    1：用户级程序可以访问
    PWTPage Write Through[3]写穿透位，实验中不会用到，可以不用了解
    PCDPage Cache Disable[4]禁用缓存位，实验中不会用到，可以不用了解
    AAccessed[5]访问位
    0：页面在上次清除这个位之后没有被访问过
    1：页面在上次清除这个位之后被访问过
    DDirty[6]脏位
    0：页面在上次清除这个位之后没有被写过
    1：页面在上次清除这个位之后被写过
    PATPage Attribute Table[7]用于指示内存缓存类型 (Memory caching type)，实验中不会用到，可以不用了解
    GGlobal[8]全局页面位，使得TLB缓存中的页表项不会随着CR3寄存器的更改而失效，实验中不会用到，可以不用了解
    Address-[31:12]地址高20位
    +

    尽管在前文的描述中，好像一二级页表中页表项结构是相同的，但实际上它们在某些位的功能上存在一部分差异，这部分差异即使是我自己在实现的时候也忽略了，直到写这一份日志仔细查阅Wikipedia时才发现。在二级页表中，它的目录项第6位、第7位和第8位的含义有所不同，其中第6、8位在二级页表的页表项中作保留位，而第7位的属性描述如下：

    + + + + + + + + + + + + + + + + + +
    简写全称位描述
    PSPage Size[7]页大小位
    0：页大小为4KiB
    1：页大小为4MiB
    在实验中使用4KiB大小的页，所以这一位始终为0
    +

    为了简便起见，我在实验中采用了不那么安全的实现：我将两种不同的属性合并在同一个位枚举类当中，并在后续的使用中主动避免使用不符合类型的属性。如同在硬盘驱动和FAT中介绍的位枚举类那样，页表项中的属性位可以抽象如下：

    +
    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
    class PageFlag {
        public:
            enum ATTRIBUTES {    
                _EMPTY          = 0,
                PRESENT         = 1,
                WRITABLE        = 1 << 1,
                USER_ACCESSIBLE = 1 << 2,
                WRITE_THROUGH   = 1 << 3,
                NO_CACHE        = 1 << 4,
                ACCESSED        = 1 << 5,
                DIRTY           = 1 << 6,
                HUGE_PAGE       = 1 << 7,
                GLOBAL          = 1 << 8,
                BIT_7           = 1 << 7,
                BIT_8           = 1 << 8,
                BIT_9           = 1 << 9,
                BIT_10          = 1 << 10,
                BIT_11          = 1 << 11,
                _ALL            = 0xFFF,
            };
        private:
            uint16 _attr;
        public:
            PageFlag();
            PageFlag(uint16 flags);
        public:
            PageFlag& operator=(uint16 flags);
            PageFlag& operator=(const PageFlag& other);
            //Judge whether two flags are equal
            bool operator==(uint16 flags);
            //Combine two flags
            PageFlag operator+(uint16 flags);
            PageFlag& operator+=(uint16 flags);
            //Remove flags
            PageFlag operator-(uint16 flags);
            PageFlag& operator-=(uint16 flags);
            //Bitwise or
            PageFlag operator|(uint16 flags);
            PageFlag& operator|=(uint16 flags);
            //Bitwise and
            PageFlag operator&(uint16 flags);
            PageFlag& operator&=(uint16 flags);
            //Reverse flags
            PageFlag operator~();
            //Toggle flag bits
            PageFlag& operator^=(uint16 flags);
            //Judge whether flags are contained
            bool contains(uint16 flags);
            uint16 val();
    };
    +

    对应的实现在复制之前的枚举类函数的基础上对参数类型进行修改，对应_attr变量的类型即可：

    +
    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
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    PageFlag::PageFlag() {
        _attr = 0;
    }
    PageFlag::PageFlag(uint16 flags) {
        _attr = flags;
    }
    PageFlag& PageFlag::operator=(uint16 flags) {
        _attr = flags;
        return *this;
    }
    PageFlag& PageFlag::operator=(const PageFlag& other) {
        _attr = other._attr;
        return *this;
    }
    //Judge whether two flags are equal
    bool PageFlag::operator==(uint16 flags) {
        return _attr == flags;
    }
    //Combine two flags
    PageFlag PageFlag::operator+(uint16 flags) {
        uint16 newAttr = _attr | flags;
        return PageFlag(newAttr);
    }
    PageFlag& PageFlag::operator+=(uint16 flags) {
        _attr |= flags;
        return *this;
    }
    //Remove flags
    PageFlag PageFlag::operator-(uint16 flags) {
        uint16 newAttr = _attr & ~(flags);
        return PageFlag(newAttr);
    }
    PageFlag& PageFlag::operator-=(uint16 flags) {
        _attr &= ~(flags);
        return *this;
    }
    //Bitwise or
    PageFlag PageFlag::operator|(uint16 flags) {
        uint16 newAttr = _attr | flags;
        return PageFlag(newAttr);
    }
    PageFlag& PageFlag::operator|=(uint16 flags) {
        _attr |= flags;
        return *this;
    }
    //Bitwise and
    PageFlag PageFlag::operator&(uint16 flags) {
        uint8 newAttr = _attr & flags;
        return PageFlag(newAttr);
    }
    PageFlag& PageFlag::operator&=(uint16 flags) {
        _attr &= flags;
        return *this;
    }
    //Reverse flags
    PageFlag PageFlag::operator~() {
        return PageFlag(_attr);
    }
    //Toggle flag bits
    PageFlag& PageFlag::operator^=(uint16 flags) {
        _attr ^= flags;
        return *this;
    }
    //Judge whether flags are contained
    bool PageFlag::contains(uint16 flags) {
        return (_attr & flags) == flags;
    }
    uint16 PageFlag::val() {
        return _attr;
    }
    +

    接着，就可以抽象页表项的结构了，由上表可以看出，页表项就是由高20位的地址位和低12位的属性位组成。在实现中我选择将整个页表项的值视作一整个变量进行存储：

    +
    1
    2
    3
    4
    class PageTableEntry {
        private:
            uint32 _val = 0;
    }
    +

    然后再为类添加从值中解析出地址和属性或是根据参数设置值中的地址位和属性位的成员函数：

    +
    1
    2
    3
    4
    5
    6
    public:
        bool isPresent() const;
        uint32 address() const;
        void setAddress(uint32 addr);
        PageFlag flags() const;
        void setFlags(PageFlag flags);
    +

    为了方便类的实例或是指针的构造，额外添加构造函数和静态成员函数如下：

    +
    1
    2
    3
    4
    public:
        static PageTableEntry* from(uint32 addr);
        PageTableEntry() {}
        PageTableEntry(uint32 addr, PageFlag flags);
    +

    小技巧：
    +在后面的编程实践中，由于我们往往拿到的都是某个页表项的地址，而不是一个页表项的实例。
    +对于像页表项这样比较复杂的结构，如果直接通过地址和指针的解引用然后再对其中的内容进行解析，则会让代码的可读性变得很差，例如获得页表项中存储的地址可以用uint32 address = (*ptr) & 0xFFFFF000实现。
    +但由于指针具有可以随意其指向的内容的类型的特性，可以通过将一个指针转换为对应结构的类（例如PageTableEntry）的指针，然后就可以通过指针来调用类的成员结构，从而实现代码重用，并且也让代码的可读性得到了提高。
    +例如，原先的操作也可以通过uint32 address = (PageTableEntry*)ptr->address()实现，而这种实现不但可以实现address()的重用，还一下就能够看出语句的目的是获得页表项中存储的地址。
    +而static PageTableEntry* from(uint32 addr);这样的函数其实就是为了我们能够更方便也更美观地进行指针的类型转换：PageTableEntry::from(ptr)肯定要比(PageTableEntry*)ptr看起来更合理，并且在某些特定的情形下，这样的转换函数内还可以添加额外的判断，让类型的转换更加安全。

    +
    +

    PageTableEntry类的全部定义如下：

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    class PageTableEntry {
        private:
            uint32 _val = 0;
        public:
            static PageTableEntry* from(uint32 addr);
            PageTableEntry() {}
            PageTableEntry(uint32 addr, PageFlag flags);
            bool isPresent() const;
            uint32 address() const;
            void setAddress(uint32 addr);
            PageFlag flags() const;
            void setFlags(PageFlag flags);
    };
    +

    其中函数的实现如下：

    +
    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
    PageTableEntry* PageTableEntry::from(uint32 addr) {
        return (PageTableEntry*)addr;
    }

    PageTableEntry::PageTableEntry(uint32 addr, PageFlag flags) {
        _val = addr & 0xFFFFF000;
        _val |= (flags.val() & 0xFFF);
    }

    bool PageTableEntry::isPresent() const {
        return flags().contains(PageFlag::PRESENT);
    }

    uint32 PageTableEntry::address() const {
        return _val & 0xFFFFF000;
    }

    void PageTableEntry::setAddress(uint32 addr) {
        _val &= 0x00000FFF;
        _val |= (addr & 0xFFFFF000);
    }

    PageFlag PageTableEntry::flags() const {
        return _val & 0xFFF;
    }

    void PageTableEntry::setFlags(PageFlag flags) {
        _val &= 0xFFFFF000;
        _val |= (flags.val() & 0xFFF);
    }
    +

    而对于页表而言，它的实现就更加简单了，由于它在 4KiB4KiB 的页大小下本质就是一个长度位1024的数组，所以其成员变量就是一个长度为1024的数组变量：

    +
    1
    2
    3
    4
    class PageTable {
        private:
            PageTableEntry _entries[1024];
    }
    +

    而由于页表本身不需要实现太多的功能，在目前实验中只需要对页表进行初始化以及取出页表中的第idx个页表项，所以其成员函数也十分简单：

    +
    1
    2
    3
    public:
        PageTableEntry& at(uint32 idx);
        void init();
    +

    除此之外，由于页表可能是一级页表也可能是二级页表，对于一级页表而言，一般一级页表都是直接拿到地址，所以需要添加一个由32位地址转换为页表对象指针的静态成员函数；而二级页表都是要从一级页表中获得了页表项，解析出地址，然后再转换为二级页表对象的指针，稍微有点麻烦，所以不妨添加一个由PageTableEntry类的对象直接转换为页表对象指针的静态成员函数。

    +
    1
    2
    3
    public:
        static PageTable* from(const PageTableEntry& entry);
        static PageTable* from(const uint32 addr);
    +

    完整的PageTable类定义如下：

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    class PageTable {
        private:
            PageTableEntry _entries[1024];
        public:
            static PageTable* from(const PageTableEntry& entry);
            static PageTable* from(const uint32 addr);
            PageTableEntry& at(uint32 idx);
            void init();
    };
    +

    其中的成员函数实现如下：

    +
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    PageTable* PageTable::from(const PageTableEntry& entry) {
        return (PageTable*)entry.address();
    }

    PageTable* PageTable::from(const uint32 addr) {
        return (PageTable*)addr;
    }

    PageTableEntry& PageTable::at(uint32 idx) {
        return _entries[idx];
    }

    void PageTable::init() {
        for(int i = 0; i < 1024; i++) {
            _entries[i] = PageTableEntry();
        }
    }
    + + + + + + + +

    勇者奖章
    +恭喜你，读完了所有日志中最长最复杂的一篇，后面的实验之路将会因这一章的努力而愈发平坦。

    +
    diff --git a/source/assets/os-journal-vol-4/elf_format.pdf b/source/assets/os-journal-vol-4/elf_format.pdf new file mode 100644 index 0000000..34b9e8c Binary files /dev/null and b/source/assets/os-journal-vol-4/elf_format.pdf differ diff --git a/source/assets/os-journal-vol-4/fat_specification.pdf b/source/assets/os-journal-vol-4/fat_specification.pdf new file mode 100644 index 0000000..59c2082 Binary files /dev/null and b/source/assets/os-journal-vol-4/fat_specification.pdf differ diff --git a/source/img/blog-mig/replace.png b/source/img/blog-mig/replace.png new file mode 100644 index 0000000..8f9ee58 Binary files /dev/null and b/source/img/blog-mig/replace.png differ diff --git a/source/img/os-journal-vol-1/IMG_20220716-113134498.png b/source/img/os-journal-vol-1/IMG_20220716-113134498.png new file mode 100644 index 0000000..e5b008a Binary files /dev/null and b/source/img/os-journal-vol-1/IMG_20220716-113134498.png differ diff --git a/source/img/os-journal-vol-1/IMG_20220716-115254230.png b/source/img/os-journal-vol-1/IMG_20220716-115254230.png new file mode 100644 index 0000000..68711a0 Binary files /dev/null and b/source/img/os-journal-vol-1/IMG_20220716-115254230.png differ diff --git a/source/img/os-journal-vol-1/IMG_20220716-160607671.png b/source/img/os-journal-vol-1/IMG_20220716-160607671.png new file mode 100644 index 0000000..970b0eb Binary files /dev/null and b/source/img/os-journal-vol-1/IMG_20220716-160607671.png differ diff --git a/source/img/os-journal-vol-2/IMG_20220719-114214235.png b/source/img/os-journal-vol-2/IMG_20220719-114214235.png new file mode 100644 index 0000000..5130022 Binary files /dev/null and b/source/img/os-journal-vol-2/IMG_20220719-114214235.png differ diff --git a/source/img/os-journal-vol-2/IMG_20220719-155923542.png b/source/img/os-journal-vol-2/IMG_20220719-155923542.png new file mode 100644 index 0000000..707ab1c Binary files /dev/null and b/source/img/os-journal-vol-2/IMG_20220719-155923542.png differ diff --git a/source/img/os-journal-vol-3/IMG_20220721-161302861.png b/source/img/os-journal-vol-3/IMG_20220721-161302861.png new file mode 100644 index 0000000..00542d7 Binary files /dev/null and b/source/img/os-journal-vol-3/IMG_20220721-161302861.png differ diff --git a/source/img/os-journal-vol-3/IMG_20220721-194409347.png b/source/img/os-journal-vol-3/IMG_20220721-194409347.png new file mode 100644 index 0000000..707ab1c Binary files /dev/null and b/source/img/os-journal-vol-3/IMG_20220721-194409347.png differ diff --git a/source/img/os-journal-vol-4/IMG_20220809-143742401.png b/source/img/os-journal-vol-4/IMG_20220809-143742401.png new file mode 100644 index 0000000..58095a3 Binary files /dev/null and b/source/img/os-journal-vol-4/IMG_20220809-143742401.png differ diff --git a/source/img/os-journal-vol-4/IMG_20220811-112229643.png b/source/img/os-journal-vol-4/IMG_20220811-112229643.png new file mode 100644 index 0000000..b379093 Binary files /dev/null and b/source/img/os-journal-vol-4/IMG_20220811-112229643.png differ diff --git a/source/img/os-journal-vol-4/IMG_20220811-140255236.png b/source/img/os-journal-vol-4/IMG_20220811-140255236.png new file mode 100644 index 0000000..e027c5f Binary files /dev/null and b/source/img/os-journal-vol-4/IMG_20220811-140255236.png differ diff --git a/source/img/os-journal-vol-4/IMG_20220811-144251284.png b/source/img/os-journal-vol-4/IMG_20220811-144251284.png new file mode 100644 index 0000000..f9469f6 Binary files /dev/null and b/source/img/os-journal-vol-4/IMG_20220811-144251284.png differ diff --git a/source/img/os-journal-vol-4/IMG_20220811-164836695.png b/source/img/os-journal-vol-4/IMG_20220811-164836695.png new file mode 100644 index 0000000..cf85433 Binary files /dev/null and b/source/img/os-journal-vol-4/IMG_20220811-164836695.png differ diff --git a/source/img/os-journal-vol-4/IMG_20220812-101149499.png b/source/img/os-journal-vol-4/IMG_20220812-101149499.png new file mode 100644 index 0000000..28abae3 Binary files /dev/null and b/source/img/os-journal-vol-4/IMG_20220812-101149499.png differ diff --git a/source/img/os-journal-vol-4/IMG_20220817-203133597.png b/source/img/os-journal-vol-4/IMG_20220817-203133597.png new file mode 100644 index 0000000..11e1178 Binary files /dev/null and b/source/img/os-journal-vol-4/IMG_20220817-203133597.png differ diff --git a/source/img/os-journal-vol-4/IMG_20220820-194513712.png b/source/img/os-journal-vol-4/IMG_20220820-194513712.png new file mode 100644 index 0000000..df8d319 Binary files /dev/null and b/source/img/os-journal-vol-4/IMG_20220820-194513712.png differ