虚拟机

QEMU 工作原理

单纯使用 qemu，采用的是完全虚拟化的模式。qemu 向 Guest OS 模拟 CPU，也模拟其他的硬件，GuestOS 认为自己和硬件直接打交道，其实是同 qemu 模拟出来的硬件打交道，qemu 会将这些指令转译给真正的硬件。由于所有的指令都要从 qemu 里面过一手，因而性能就会比较差。

完全虚拟化是非常慢的，所以要使用硬件辅助虚拟化技术 Intel-VT，AMD-V，所以需要 CPU 硬件开启这个标志位，一般在 BIOS 里面设置。当确认开始了标志位之后，通过 KVM，GuestOS 的 CPU 指令不用经过 Qemu 转译，直接运行，大大提高了速度。所以，KVM 在内核里面需要有一个模块，来设置当前 CPU 是 Guest OS 在用，还是 Host OS 在用。

可以通过如下命令查看内核模块中是否有 KVM

lsmod | grep kvm

KVM 内核模块通过 /dev/kvm 暴露接口，用户态程序可以通过 ioctl来访问这个接口。Qemu 将 KVM 整合进来，将有关 CPU 指令的部分交由内核模块来做，就是 qemu-kvm (qemu-system-XXX)。

qemu 和 kvm 整合之后，CPU 的性能问题解决了。另外 Qemu 还会模拟其他的硬件，如网络和硬盘。同样，全虚拟化的方式也会影响这些设备的性能。

于是，qemu 采取半虚拟化的方式，让 Guest OS 加载特殊的驱动来做这件事情。

例如，网络需要加载 virtio_net，存储需要加载 virtio_blk，Guest 需要安装这些半虚拟化驱动，GuestOS 知道自己是虚拟机，所以数据会直接发送给半虚拟化设备，经过特殊处理（例如排队、缓存、批量处理等性能优化方式），最终发送给真正的硬件。这在一定程度上提高了性能。

计算虚拟化之 CPU

计算虚拟化之内存

源码

//process.c
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
extern int create_process (char* program, char** arg_list);
int create_process (char* program, char** arg_list)
{
    pid_t child_pid;
    child_pid = fork ();
    if (child_pid != 0)
    {
        return child_pid;
    }
    else 
    {
        execvp (program, arg_list);
        abort ();
    }
}

在这里，我们创建的子程序运行了一个最最简单的命令 ls。

//createprocess.c
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
extern int create_process (char* program, char** arg_list);
int main ()
{
    char* arg_list[] = {
        "ls",
        "-l",
        "/etc/yum.repos.d/",
        NULL
    };
    create_process ("ls", arg_list);
    return 0;
}

编译

CPU 看不懂源码里的函数，命令，CPU 只认二进制数据，所以源码需要翻译成01二进制数据，这个过程就是**编译（Compile）**的过程。

编译出的文件好比一个公司的项目执行计划书，你要把一个项目执行好，计划书得有章法，有一定格式。在 Linux 下，二进制程序也有这样的格式，叫ELF（Executeable and Linkable Format，可执行与可链接格式），这个格式可以根据编译的结果不同，分为不同的格式。

ELF-可重定位文件

下图展示了如何从源码到二进制文件的转化

gcc -c -fPIC process.c
gcc -c -fPIC createprocess.c

-fPIC作用于编译阶段，告诉编译器产生与位置无关代码 (Position-Independent Code)。产生的代码中，没有绝对地址，全部使用相对地址，故而代码可以被加载器加载到内存的任意位置，都可以正确的执行。

在编译的时候，先做预处理工作，例如将头文件嵌入到正文中，将定义的宏展开，然后就是真正的编译过程，最终编译成为.o文件，这就是ELF的第一种类型，可重定位文件（Relocatable File）。文件格式如下，

ELF 文件的头是用于描述整个文件的。这个文件格式在内核中有定义，分别为 struct elf32_hdr 和 struct elf64_hdr。

第一种 ELF 文件叫可重定位文件，为啥可重定位？我们可以想象一下，这个编译好的代码和变量，将来加载到内存里面的时候，都是要加载到一定位置的。比如说，调用一个函数，其实就是跳到这个函数所在的代码位置执行；再比如修改一个全局变量，也是要到变量的位置那里去修改。但是现在这个时候，还是.o文件，不是一个可以直接运行的程序，这里面只是部分代码片段。

例如这里的 create_process函数，将来被谁调用，在哪里调用都不清楚，就更别提确定位置了。所以，.o里面的位置是不确定的，但是必须是可重新定位的，因为它将来是要做函数库的嘛，就是一块砖，哪里需要哪里搬，搬到哪里就重新定位这些代码、变量的位置。

ELF-可执行文件

要让create_process这个函数作为库文件重用，需要将其形成库文件，最简单的类型是静态链接库.a文件，它将一系列.o文件归档为一个文件。使用ar命令创建.a文件。使用方法看这里。

ar cr libstaticprocess.a process.o

虽然这里 libstaticprocess.a 里面只有一个.o，但是实际情况可以有多个.o。当有程序要使用这个静态连接库的时候，会将.o 文件提取出来，链接到程序中。

gcc -o staticcreateprocess createprocess.o -L. -lstaticprocess

-L表示在当前目录下找.a文件，-lstaticprocess 会自动补全文件名，比如加前缀 lib，后缀.a，变成 libstaticprocess.a，找到这个.a文件后，将里面的 process.o 取出来，和 createprocess.o 做一个链接，形成二进制执行文件 staticcreateprocess。

在链接过程中，重定位就起作用了，在createprocess.o里调用了create_process函数，但是不能确定位置，现在将process.o合并进来，就知道位置了。

这个格式和.o 文件大致相似，还是分成一个个的 section，并且被节头表描述。只不过这些section 是多个.o 文件合并过的。但是这个时候，这个文件已经是马上就可以加载到内存里面执行的文件了，因而这些 section 被分成了需要加载到内存里面的代码段、数据段和不需要加载到内存里面的部分，将小的 section 合成了大的段 segment，并且在最前面加一个段头表（Segment Header Table）。

在代码里面的定义为 struct elf32_phdr和 struct elf64_phdr，这里面除了有对于段的描述之外，最重要的是 p_vaddr，这个是这个段加载到内存的虚拟地址。

在 ELF 头里面，有一项 e_entry，也是个虚拟地址，是这个程序运行的入口。

ELF-共享对象文件

静态库一旦被链接，代码和变量的section会被合并，所以运行时不依赖静态库文件，但是缺点就是，相同代码段被多个程序使用，在内存里会有多份，而且静态库更新需要重新编译。

因而就出现了另一种，动态链接库（Shared Libraries），不仅仅是一组对象文件的简单归档，而是多个对象文件的重新组合，可被多个程序共享。

gcc -shared -fPIC -o libdynamicprocess.so process.o

当一个动态链接库被链接到一个程序文件中的时候，最后的程序文件并不包括动态链接库中的代码，而仅仅包括对动态链接库的引用，并且不保存动态链接库的全路径，仅仅保存动态链接库的名称。

gcc -o dynamiccreateprocess createprocess.o -L. -ldynamicprocess

当运行这个程序的时候，首先寻找动态链接库，然后加载它。默认情况下，系统在 /lib 和/usr/lib 文件夹下寻找动态链接库。如果找不到就会报错，我们可以设定 LD_LIBRARY_PATH环境变量，程序运行时会在此环境变量指定的文件夹下寻找动态链接库。

# export LD_LIBRARY_PATH=.
# ./dynamiccreateprocess
# total 40
-rw-r--r--. 1 root root 1572 Oct 24 18:38 CentOS-Base.repo
......

动态链接库，就是ELF的第三种类型，共享对象文件（Shared Object）。

文件格式和上两种文件稍有不同，首先，多了一个.interp的 Segment，这里面是 ld-linux.so，这是动态链接器，也就是说，运行时的链接动作都是它做的。

另外，ELF文件中还多了两个section，一个是.plt，过程链接表（Procedure Linkage Table，PLT），一个是。got.plt，全局偏移量表（Global Offset Table，GOT）。

运行

在内核中，有linux_binfmt elf_format数据结构定义了加载 ELF 的方法，使用load_elf_binary加载二进制文件，该函数由do_execve调用，学过系统调用知道exec调用了do_execve函数。所以流程为

exec->do_execve->load_elf_binary

进程树

所有进程都是从父进程 fork 来的，祖宗进程就是init 进程。

系统启动之后，init 进程会启动很多的daemon 进程，为系统运行提供服务，然后就是启动 getty，让用户登录，登录后运行 shell，用户启动的进程都是通过 shell运行的，从而形成了一棵进程树。

我们可以通过 ps -ef命令查看当前系统启动的进程，我们会发现有三类进程。PID 1 的进程就是我们的init进程 systemd，PID 2 的进程是内核线程 kthreadd。

内核态进程的PPID祖先进程都是 2 号进程，用户态进程祖先进程都是 1 号进程，tty列是问号的，说明是后台服务进程。

进程数据结构

在 Linux 里面，无论是进程还是线程，到了内核里面，我们统一都叫任务（Task），由一个统一的结构task_struct进行管理。

每个任务应该包含的字段：

任务 ID

pid_t pid; #process id
pid_t tgid; #thread group ID
struct task_struct *group_leader; 

为何要有这么多 ID，一个不够吗？

• 可以方便任务展示，比如在命令行中 ps 显示所有进程，只显示pid_t pid，而不会把所有内部线程摊开展示，这样太碍眼。
• 方便下达命令，当我 kill 一个进程时，我们是对整个进程发送信号，但是有时候一些命令只需要对某个线程发送信号。

信号处理

/* Signal handlers: */
struct signal_struct    *signal;
struct sighand_struct    *sighand;
sigset_t      blocked;
sigset_t      real_blocked;
sigset_t      saved_sigmask;
struct sigpending    pending;
unsigned long      sas_ss_sp;
size_t        sas_ss_size;
unsigned int      sas_ss_flags;

这里定义了哪些信号被阻塞暂不处理（blocked），哪些信号尚等待处理（pending），哪些信号正在通过信号处理函数进行处理（sighand）。处理的结果可以是忽略，可以是结束进程等等。

任务状态

volatile long state;    /* -1 unrunnable, 0 runnable, >0 stopped */

int exit_state;

unsigned int flags;

state可取值定义如下

/* Used in tsk->state: */
#define TASK_RUNNING                    0
#define TASK_INTERRUPTIBLE              1
#define TASK_UNINTERRUPTIBLE            2
#define __TASK_STOPPED                  4
#define __TASK_TRACED                   8
/* Used in tsk->exit_state: */
#define EXIT_DEAD                       16
#define EXIT_ZOMBIE                     32
#define EXIT_TRACE                      (EXIT_ZOMBIE | EXIT_DEAD)
/* Used in tsk->state again: */
#define TASK_DEAD                       64
#define TASK_WAKEKILL                   128
#define TASK_WAKING                     256
#define TASK_PARKED                     512
#define TASK_NOLOAD                     1024
#define TASK_NEW                        2048
#define TASK_STATE_MAX                  4096

可以发现 Linux 通过 bitset 方式设置状态，当前什么状态，哪一位就置 1。

进程调度

进程的状态切换往往涉及调度，下面这些字段都是用于调度的。

// 是否在运行队列上
int               on_rq;
// 优先级
int               prio;
int               static_prio;
int               normal_prio;
unsigned int      rt_priority;
// 调度器类
const struct sched_class  *sched_class;
// 调度实体
struct sched_entity       se;
struct sched_rt_entity    rt;
struct sched_dl_entity    dl;
// 调度策略
unsigned int      policy;
// 可以使用哪些 CPU
int            nr_cpus_allowed;
cpumask_t      cpus_allowed;
struct sched_info    sched_info;

运行统计信息

u64        utime;// 用户态消耗的 CPU 时间
u64        stime;// 内核态消耗的 CPU 时间
unsigned long      nvcsw;// 自愿 (voluntary) 上下文切换计数
unsigned long      nivcsw;// 非自愿 (involuntary) 上下文切换计数
u64        start_time;// 进程启动时间，不包含睡眠时间
u64        real_start_time;// 进程启动时间，包含睡眠时间

进程亲缘关系

进程有棵进程树，所以有亲缘关系。

struct task_struct __rcu *real_parent; /* real parent process */
struct task_struct __rcu *parent; /* recipient of SIGCHLD, wait4() reports */
struct list_head children;      /* list of my children */
struct list_head sibling;       /* linkage in my parent's children list */

通常情况下，real_parent 和 parent 是一样的，但是也会有另外的情况存在。例如，bash 创建一个进程，那进程的 parent 和 real_parent 就都是 bash。如果在 bash 上使用 GDB 来 debug 一个进程，这个时候 GDB 是 real_parent，bash 是这个进程的 parent。

进程权限

/* Objective and real subjective task credentials (COW): */
const struct cred __rcu         *real_cred;
/* Effective (overridable) subjective task credentials (COW): */
const struct cred __rcu   

real_cred 就是说明谁能操作我这个进程，而 cred 就是说明我这个进程能够操作谁。

总结到一起，task_struct结构图如下，

x86 架构概述

CPU（Central Processing Unit）：中央处理器，计算机所有设备都围绕它展开工作。

• 运算单元：只管算，例如做加法、做位移等等。但是，它不知道应该算哪些数据，运算结果应该放在哪里。
• 数据单元：运算单元计算的数据如果每次都要经过总线，到内存里面现拿，这样就太慢了，所以就有了数据单元。数据单元包括 CPU 内部的缓存和寄存器组，空间很小，但是速度飞快，可以暂时存放数据和运算结果。
• 控制单元：有了放数据的地方，也有了算的地方，还需要有个指挥到底做什么运算的地方，这就是控制单元。控制单元是一个统一的指挥中心，它可以获得下一条指令，然后执行这条指令。这个指令会指导运算单元取出数据单元中的某几个数据，计算出个结果，然后放在数据单元的某个地方。

内存（Memory）：CPU 本身不能保存大量数据，许多复杂的计算需要将中间结果保存下来就必须用到内存。

总线（Bus）：CPU 和其他设备连接，就靠总线，其实就是主板上密密麻麻的集成电路，这些东西组成了 CPU 和其他设备的高速通道。

• 地址总线：传输地址数据（我想拿内存中哪个位置的数据）
• 数据总线：传输真正的数据

总线就像 CPU 和内存之间的高速公路，总线多少位就类似高速公路多少个车道，但两种总线的位数意义不同。

地址总线的位数决定了访问地址范围有多广，数据总线位数决定了一次能拿多少数据进来。那么 CPU 中总线的位数有没有标准呢？如果没有标准，那操作系统作为软件就很难办了，因为软件层没办法实现通用的运算逻辑。早期每家公司的 CPU 架构都不同，后来历史将 x86 平台推到了开放，统一，兼容的位置。

8086 架构图

数据单元： 8086 处理器内部共有 8 个 16 位的通用寄存器，分别是 数据寄存器（AX、BX、CX、DX）、指针寄存器（SP、BP）、变址寄存器（SI、DI）。其中 AX、BX、CX、DX 可以分成两个 8 位的寄存器来使用，分别是 AH、AL、BH、BL、CH、CL、DH、DL，其中 H 就是 High（高位），L 就是 Low（低位）的意思。

控制单元： IP 寄存器（Instruction Pointer Register）就是指令指针寄存器，它指向代码段中下一条指令的位置。CPU 会根据它来不断地将指令从内存的代码段中，加载到 CPU 的指令队列中，然后交给运算单元去执行。

如果需要切换进程呢？每个进程都分代码段和数据段，为了指向不同进程的地址空间，有四个 16 位的段寄存器，分别是 CS、DS、SS、ES。

其中，CS 就是代码段寄存器（Code Segment Register），通过它可以找到代码在内存中的位置；DS 是数据段的寄存器（Data Segment Register），通过它可以找到数据在内存中的位置。SS 是栈寄存器（Stack Register）。栈是程序运行中一个特殊的数据结构，数据的存取只能从一端进行，秉承后进先出的原则。ES是扩展段寄存器（Extra Segment Register）顾名思义。

如果 CPU 运算中需要加载内存中的数据，需要通过 DS 找到内存中的数据，加载到通用寄存器中，应该如何加载呢？对于一个段，有一个起始的地址，而段内的具体位置，我们称为偏移量（Offset）。在 CS 和 DS 中都存放着一个段的起始地址。代码段的偏移量在 IP 寄存器中，数据段的偏移量会放在通用寄存器中。因为段寄存器都是 16 位的，而地址总线是 20 位的，所以通过 *起始地址 16+ 偏移量 的方式，将寻址位数都变成 20 位，也就是将 CS 和 DS 的值左移 4 位。

对于只有 20 位地址总线的 8086 来说，寻址空间最大也就是$2^{20}=1\text{M}$，超过这个位置就访问不到了，一个段因为偏移量只有 16 位，所以一个段最大是$2^{16}=64\text{k}$。

32 位处理器

随着计算机发展，内存越来越大，总线也越来越宽。在 32 位处理器中，有 32 根地址总线，可以访问 $2^{32}=4\text{G}$ 的内存。使用原来的模式肯定不行了，但是又不能完全抛弃原来的模式，因为这个架构是开放的。那么在开发架构的基础上如何保持兼容呢？

首先，通用寄存器有扩展，可以将 8 个 16 位的扩展到 8 个 32 位的，但是依然可以保留 16 位的和 8 位的使用方式。其中，指向下一条指令的指令指针寄存器 IP，就会扩展成 32 位的，同样也兼容 16 位的。

段寄存器改动较大，新的段寄存器都改成了 32 位的，每个寄存器又分为段描述符缓存器（Segment Descriptor），和段选择子寄存器（Selector） ,现在的段寄存器不在是段的起始地址，段的起始地址保存在表格一样的段描述符缓冲器中，段选择子寄存器保存地址在段描述符缓存器中的哪一项。这样，将一个从段寄存器直接拿到的段起始地址，就变成了先间接地从段寄存器找到表格中的一项，再从表格中的一项中拿到段起始地址。

虽然现在的这种模式和之前的模式不兼容，但是后面这种模式灵活的非常高，可以保持一直兼容下去。在 32 位的系统架构下，将前一种模式称为实模式（Real Pattern），后一种模式称为保护模式（Protected Pattern） 。当系统刚刚启动的时候，CPU 是处于实模式的，这个时候和原来的模式是兼容的。也就是说，哪怕你买了 32 位的 CPU，也支持在原来的模式下运行。

汇编命令学习 mov, call, jmp, int, ret, add, or, xor, shl, shr, push, pop, inc, dec, sub, cmp。

BIOS 与 BootLoader

BIOS：基本输入输出系统

ROM：只读存储器

RAM：随机存取存储器

在我们按下电脑电源键的那一刻，主板就加电了，CPU 就要开始执行指令了，但是刚开始操作系统都没，CPU 执行什么指令呢？这就有了BIOS，它相当于一个指导手册，告诉 CPU 接下来要干啥。

刚开机时，系统初始化代码从 ROM 读取，将 CS 设置为 0xFFFF，将 IP 设置为 0x0000，所以第一条指令就会指向 0xFFFF0，初始化完成后确定访问指令位置。

接下来 BIOS 会检查各个硬件是否正常，检测内容显卡等关键部件的存在于工作状态，设备初始化，执行系统 BIOS 进行系统检测，更新 CMOS 中的扩展系统配置数据 ESCD。这期间也会建立中断向量表和中断服务程序，因为要使用键盘鼠标都需要中断进行。

下一步 BIOS 就得要找操作系统了，操作系统一般安装在硬盘上，但是 BIOS 得先找到启动盘，启动盘一般安装在第一个扇区，占 512 字节，会包含启动的相关代码。在 Linux 中，可以通过Grub2配置这些代码。

grub2-mkconfig -o /boot/grub2/grub.cfg

grub2第一个要安装的就是boot.img。它由 boot.S编译而成，一共 512 字节，正式安装到启动盘的第一个扇区。这个扇区通常称为MBR（Master Boot Record，主引导记录 / 扇区）。

BIOS 完成任务后，会将 boot.img 从硬盘加载到内存中的 0x7c00来运行。

由于 512 个字节实在有限，boot.img 做不了太多的事情。它能做的最重要的一个事情就是加载grub2 的另一个镜像 core.img。

core.img 由lzma_decompress.img、diskboot.img、kernel.img 和一系列的模块组成，功能比较丰富，能做很多事情。

boot.img 先加载的是 core.img 的第一个扇区。如果从硬盘启动的话，这个扇区里面是diskboot.img，对应的代码是 diskboot.S。

boot.img 将控制权交给 diskboot.img 后，diskboot.img 的任务就是将core.img 的其他部分加载进来，先是解压缩程序 lzma_decompress.img，再往下是 kernel.img，最后是各个模块module对应的映像。这里需要注意，它不是 Linux 的内核，而是grub 的内核。

在这之前，我们所有遇到过的程序都非常非常小，完全可以在实模式下运行，但是随着我们加载的东西越来越大，实模式这1M 的地址空间实在放不下了，所以在真正的解压缩之前，lzma_decompress.img 做了一个重要的决定，就是调用 real_to_prot，切换到保护模式，这样就能在更大的寻址空间里面，加载更多的东西。

BIOS将加载程序从硬盘的引导扇区加载到指定位置，再跳转到指定位置，将控制权转交给加载程序。加载程序将操作系统代码读取到内存，并将控制权转到操作系统。

Q：BIOS-操作系统，中间经过加载程序。为何不直接读取？ A：磁盘文件系统多种多样，硬盘出厂时不能限制只能用一种文件系统，而 BIOS 也不能加上识别所有文件系统的代码。所有为了灵活性只读取磁盘的一块，由加载程序来识别磁盘的文件系统。

切换到保护模式后，将会做以下这些事，大多数都与内存访问方式有关。

首先启动分段，就是在内存里面建立段描述符表，将寄存器里面的段寄存器变成段选择子，指向某个段描述符，这样就能实现不同进程的切换了。

接着是启动分页。能够管理的内存变大了，就需要将内存分成相等大小的块。

打开 Gate20，也就是第 21 根地址线的控制线。因为在实模式 8086 下，一共就 20 根地址线，最大访问1M的地址空间。切换保护模式的函数DATA32 call real_to_prot会打开Gate A20。

现在好了，有的是空间了。接下来我们要对压缩过的 kernel.img 进行解压缩，然后跳转到 kernel.img 开始运行。

内核初始化

• start_kernel()
  • INIT_TASK(init_task)
  • trap_init()
  • mm_init()
  • sched_init()
  • rest_init()
    • kernel_thread(kernel_init, NULL,CLONE_FS)
    • kernel_thread(kthreadd, NULL, CLONE_FS | CLONE_FILES)

内核的启动从入口函数start_kernel() 开始。在 init/main.c 文件中，start_kernel 相当于内核的 main 函数。打开这个函数，我们会发现，里面是各种各样初始化函数 XXXX_init。

在操作系统里面，先要有个创始进程，有一行指令 set_task_stack_end_magic(&init_task)。这里面有一个参数 init_task，它的定义是 struct task_struct init_task = INIT_TASK(init_task)。它是系统创建的第一个进程，我们称为0号进程。这是唯一一个没有通过fork 或者kernel_thread 产生的进程，是进程列表的第一个。

trap_init()里设置了很多**中断门 (Interrupt Gate)**处理各种中断。

mm_init()初始化内存管理模块，sched_init()初始化调度模块。

vfs_caches_init() 会用来初始化基于内存的文件系统 rootfs。在这个函数里面，会调用 mnt_init()->init_rootfs()。这里面有一行代码，register_filesystem(&rootfs_fs_type)。在 VFS 虚拟文件系统里面注册了一种类型，我们定义为 struct file_system_type rootfs_fs_type。为了兼容各种各样的文件系统，我们需要将文件的相关数据结构和操作抽象出来，形成一个抽象层对上提供统一的接口，这个抽象层就是 VFS（Virtual File System），虚拟文件系统。

最后start_kernel()调用rest_init()来做其他方面的初始化，如初始化 1 号进程，内核态与用户态转化等。

rest_init 的第一大工作是，用 kernel_thread(kernel_init, NULL, CLONE_FS)创建第二个进程，这个是1 号进程。这对操作系统意义非凡，因为他将运行第一个用户进程，一旦有了用户进程，运行模式也将发生改变，之前所有资源都是给一个进程用，现在有了用户进程，就会出现抢夺资源的现象。资源也分核心和非核心资源，具有不同权限的进程可以获取不同的资源。x86提供了分层的权限机制，分成四个Ring，越往里权限越高。

操作系统很好地利用了这个机制，将能够访问关键资源的代码放在 Ring0，我们称为内核态（Kernel Mode）；将普通的程序代码放在 Ring3，我们称为用户态（User Mode）。

继续探究kernel_thread()这个函数，它的一个参数有一个函数kernel_init，在这个函数里会调用kernel_init_freeable()，里面有这样一段代码

if (!ramdisk_execute_command)
    ramdisk_execute_command = "/init";

先不管ramdisk 是啥，我们回到 kernel_init 里面。这里面有这样的代码块：

if (ramdisk_execute_command) {
  ret = run_init_process(ramdisk_execute_command);
....
}
....
if (!try_to_run_init_process("/sbin/init") ||
    !try_to_run_init_process("/etc/init") ||
    !try_to_run_init_process("/bin/init") ||
    !try_to_run_init_process("/bin/sh"))
  return 0;

我们可以发现，1 号进程运行的是一个文件，如果我们打开run_init_process函数，会发现它调用的是do_execve。

前面讲系统调用的时候，execve 是一个系统调用，它的作用是运行一个执行文件。加一个 do_ 的往往是内核系统调用的实现。没错，这就是一个系统调用，它会尝试运行 ramdisk 的“/init”，或者普通文件系统上的“/sbin/init”“/etc/init”“/bin/init”“/bin/sh”。不同版本的 Linux 会选择不同的文件启动，但是只要有一个起来了就可以。

static int run_init_process(const char *init_filename)
{
  argv_init[0] = init_filename;
  return do_execve(getname_kernel(init_filename),
    (const char __user *const __user *)argv_init,
    (const char __user *const __user *)envp_init);
}

如何利用执行 init 文件的机会，从内核态回到用户态呢？

我们从系统调用的过程可以得到启发，“用户态 - 系统调用 - 保存寄存器 - 内核态执行系统调用 - 恢复寄存器 - 返回用户态”，然后接着运行。而咱们刚才运行init，是调用 do_execve，正是上面的过程的后半部分，从内核态执行系统调用开始。

do_execve->do_execveat_common->exec_binprm->search_binary_handler，这里面会调用这段内容：

int search_binary_handler(struct linux_binprm *bprm)
{
  ......
  struct linux_binfmt *fmt;
  ......
  retval = fmt->load_binary(bprm);
  ......
}

也就是说，我要运行一个程序，需要加载这个二进制文件，这就是我们常说的项目执行计划书。它是有一定格式的。Linux 下一个常用的格式是 ELF（Executable and Linkable Format，可执行与可链接格式）。于是我们就有了下面这个定义：

static struct linux_binfmt elf_format = {
.module  = THIS_MODULE,
.load_binary  = load_elf_binary,
.load_shlib  = load_elf_library,
.core_dump  = elf_core_dump,
.min_coredump  = ELF_EXEC_PAGESIZE,
};

这其实就是先调用 load_elf_binary，最后调用 start_thread。

void
start_thread(struct pt_regs *regs, unsigned long new_ip, unsigned long new_sp)
{
set_user_gs(regs, 0);
regs->fs  = 0;
regs->ds  = __USER_DS;
regs->es  = __USER_DS;
regs->ss  = __USER_DS;
regs->cs  = __USER_CS;
regs->ip  = new_ip;
regs->sp  = new_sp;
regs->flags  = X86_EFLAGS_IF;
force_iret();
}
EXPORT_SYMBOL_GPL(start_thread);

struct pt_regs，看名字里的 register，就是寄存器啊！这个结构就是在系统调用的时候，内核中保存用户态运行上下文的，里面将用户态的代码段 CS设置为 __USER_CS，将用户态的数据段 DS 设置为 __USER_DS，以及指令指针寄存器 IP、栈指针寄存器 SP。这里相当于补上了原来系统调用里，保存寄存器的一个步骤。

最后的 iret 是干什么的呢？它是用于从系统调用中返回。这个时候会恢复寄存器。从哪里恢复呢？按说是从进入系统调用的时候，保存的寄存器里面拿出。好在上面的函数补上了寄存器。CS 和指令指针寄存器 IP 恢复了，指向用户态下一个要执行的语句。DS 和函数栈指针 SP 也被恢复了，指向用户态函数栈的栈顶。所以，下一条指令，就从用户态开始运行了。

init 终于从内核到用户态了。一开始到用户态的是 ramdisk 的 init，后来会启动真正根文件系统上的 init，成为所有用户态进程的祖先。

为什么会有 ramdisk 这个东西呢？还记得上一节咱们内核启动的时候，配置过这个参数：

initrd16 /boot/initramfs-3.10.0-862.el7.x86_64.img

就是这个东西，这是一个基于内存的文件系统。为啥会有这个呢？

是因为刚才那个 init 程序是在文件系统上的，文件系统一定是在一个存储设备上的，例如硬盘。Linux 访问存储设备，要有驱动才能访问。如果存储系统数目很有限，那驱动可以直接放到内核里面，反正前面我们加载过内核到内存里了，现在可以直接对存储系统进行访问。

但是存储系统越来越多了，如果所有市面上的存储系统的驱动都默认放进内核，内核就太大了。这该怎么办呢？

我们只好先弄一个基于内存的文件系统。内存访问是不需要驱动的，这个就是 ramdisk。这个时候，ramdisk 是根文件系统。

然后，我们开始运行 ramdisk 上的 /init。等它运行完了就已经在用户态了。/init 这个程序会先根据存储系统的类型加载驱动，有了驱动就可以设置真正的根文件系统了。有了真正的根文件系统，ramdisk上的 /init 会启动文件系统上的 init。

接下来就是各种系统的初始化。启动系统的服务，启动控制台，用户就可以登录进来了。

至此，用户态进程有了一个祖宗，那内核态的进程呢？这就是rest_init接下来要做的是，创建 2 号线程。

kernel_thread(kthreadd, NULL, CLONE_FS | CLONE_FILES)又一次使用 kernel_thread 函数创建进程。这里的函数 kthreadd，负责所有内核态的线程的调度和管理，是内核态所有线程运行的祖先。

系统调用

Linux 提供了glibc这个库封装了系统调用，方便用户使用。那么在打开一个文件时，glibc是如何调用内核的open的呢？

在 glibc 的源代码中，有个文件syscalls.list，里面列着所有 glibc 的函数对应的系统调用，就像下面这个样子：

# File name Caller  Syscall name    Args    Strong name Weak names
open    -  open    Ci:siv  __libc_open __open open

另外，glibc 还有一个脚本 make-syscall.sh，可以根据上面的配置文件，对于每一个封装好的系统调用，生成一个文件。这个文件里面定义了一些宏，例如 #define SYSCALL_NAME open。

glibc 还有一个文件 syscall-template.S，使用上面这个宏，定义了这个系统调用的调用方式。

对于任何一个系统调用，会调用DO_CALL。这也是一个宏，这个宏 32 位和 64 位的定义是不一样的。

32 位系统调用过程

i386 目录下的sysdep.h 文件

/* Linux takes system call arguments in registers:
  syscall number  %eax       call-clobbered
  arg 1    %ebx       call-saved
  arg 2    %ecx       call-clobbered
  arg 3    %edx       call-clobbered
  arg 4    %esi       call-saved
  arg 5    %edi       call-saved
  arg 6    %ebp       call-saved
......
*/
#define DO_CALL(syscall_name, args)                           
    PUSHARGS_##args                             
    DOARGS_##args                                
    movl $SYS_ify (syscall_name), %eax;                          
    ENTER_KERNEL                                 
    POPARGS_##args

这里，我们将请求参数放在寄存器里面，根据系统调用的名称，得到系统调用号，放在寄存器 eax 里面，然后执行 ENTER_KERNEL。

# define ENTER_KERNEL int $0x80

ENTER_KERNEL就是一个软中断，通过它可以陷入 (trap) 内核。

在内核启动的时候，还记得有一个 trap_init()，这是一个软中断的陷入门。当接到一个系统调用时，trap_init()就会调用entry_INT80_32。

通过 push 和 SAVE_ALL 将当前用户态的寄存器，保存在 pt_regs 结构里面，然后调用 do_syscall_32_irqs_on。

64 位系统调用过程

计算机所谓的“计算”指的是：

• 进程和线程对于 CPU 的使用
• 对内存的管理

独享内存空间的原理

每个进程都独享一段内存空间，并且真实物理内存地址对进程不可见，操作系统会给进程分配一个虚拟地址，每个进程看到的内存地址都是从 0 开始。操作系统会将不同进程的虚拟地址和不同内存的物理地址做映射。当程序访问虚拟地址时，由内核的数据结构进行转换，转换成不同的物理地址，这样不同的进程运行的时候，写入的是不同的物理地址。

规划虚拟地址空间

通过以上的原理，我们可以看出，操作系统的内存管理，主要分为三个方面。

1. 物理内存的管理；
2. 虚拟地址的管理；
3. 虚拟地址和物理地址如何映射；

进程获取了一段独立的虚拟内存空间后，可以不用管其他进程，“任意”使用这片内存，但是也有一点规则。这篇内存需要存放内核态和用户态的内容。高地址存放内核态的内容，低地址存放用户态的内容。具体分界线 64 位与 32 位不同，暂不深究。

我们从最低位开始排起，先是Text Segment、Data Segment 和 BSS Segment。Text Segment 是存放二进制可执行代码的位置，Data Segment 存放静态常量，BSS Segment 存放未初始化的静态变量。是不是觉得这几个名字很熟悉？没错，咱们前面讲 ELF 格式的时候提到过，在二进制执行文件里面，就有这三个部分。这里就是把二进制执行文件的三个部分加载到内存里面。

接下来是堆（Heap）段。堆是往高地址增长的，是用来动态分配内存的区域，malloc 就是在这里面分配的。 接下来的区域是Memory Mapping Segment。这块地址可以用来把文件映射进内存用的，如果二进制的执行文件依赖于某个动态链接库，就是在这个区域里面将 so 文件映射到了内存中。 再下面就是栈（Stack）地址段。主线程的函数调用的函数栈就是用这里的。

普通进程不能访问内核空间，如果需要进行更高权限的工作，就需要系统调用进入内核。每一段进程的内存空间存放的内容各不相同，但是进入内核后看到的都是同一个内核空间，同一个进程列表。

内核的代码访问内核的数据结构，大部分的情况下都是使用虚拟地址的，虽然内核代码权限很大，但是能够使用的虚拟地址范围也只能在内核空间，也即内核代码访问内核数据结构。

接下来，我们需要知道，如何将其映射成为物理地址呢？

咱们前面讲 x86 CPU 的时候，讲过分段机制，咱们规划虚拟空间的时候，也是将空间分成多个段进行保存。我们来看看分段机制的原理。

分段机制下的虚拟地址由两部分组成，段选择子和段内偏移量。段选择子就保存在咱们前面讲过的段寄存器里面。段选择子里面最重要的是段号，用作段表的索引。段表里面保存的是这个段的基地址、段的界限和特权等级等。虚拟地址中的段内偏移量应该位于 0 和段界限之间。如果段内偏移量是合法的，就将段基地址加上段内偏移量得到物理内存地址。

例如，我们将上面的虚拟空间分成以下 4 个段，用 0～3 来编号。每个段在段表中有一个项，在物理空间中，段的排列如下图的右边所示。如果要访问段 2 中偏移量 600 的虚拟地址，我们可以计算出物理地址为，段 2 基地址 2000 + 偏移量 600 = 2600。

在 Linux 里面，段表全称段描述符表（segment descriptors），放在全局描述符表 GDT（Global Descriptor Table）里面，会有下面的宏来初始化段描述符表里面的表项。

#define GDT_ENTRY_INIT(flags, base, limit) { { { \
    .a = ((limit) & 0xffff) | (((base) & 0xffff) << 16), \
    .b = (((base) & 0xff0000) >> 16) | (((flags) & 0xf0ff) << 8) | \
      ((limit) & 0xf0000) | ((base) & 0xff000000), \
  } } }

一个段表项由段基地址 base、段界限 limit，还有一些标识符组成。

DEFINE_PER_CPU_PAGE_ALIGNED(struct gdt_page, gdt_page) = { .gdt = {
#ifdef CONFIG_X86_64
  [GDT_ENTRY_KERNEL32_CS]    = GDT_ENTRY_INIT(0xc09b, 0, 0xfffff),
  [GDT_ENTRY_KERNEL_CS]    = GDT_ENTRY_INIT(0xa09b, 0, 0xfffff),
  [GDT_ENTRY_KERNEL_DS]    = GDT_ENTRY_INIT(0xc093, 0, 0xfffff),
  [GDT_ENTRY_DEFAULT_USER32_CS]  = GDT_ENTRY_INIT(0xc0fb, 0, 0xfffff),
  [GDT_ENTRY_DEFAULT_USER_DS]  = GDT_ENTRY_INIT(0xc0f3, 0, 0xfffff),
  [GDT_ENTRY_DEFAULT_USER_CS]  = GDT_ENTRY_INIT(0xa0fb, 0, 0xfffff),
#else
  [GDT_ENTRY_KERNEL_CS]    = GDT_ENTRY_INIT(0xc09a, 0, 0xfffff),
  [GDT_ENTRY_KERNEL_DS]    = GDT_ENTRY_INIT(0xc092, 0, 0xfffff),
  [GDT_ENTRY_DEFAULT_USER_CS]  = GDT_ENTRY_INIT(0xc0fa, 0, 0xfffff),
  [GDT_ENTRY_DEFAULT_USER_DS]  = GDT_ENTRY_INIT(0xc0f2, 0, 0xfffff),
......
#endif
} };
EXPORT_PER_CPU_SYMBOL_GPL(gdt_page);

这里面对于 64 位的和 32 位的，都定义了内核代码段、内核数据段、用户代码段和用户数据段。另外，还会定义下面四个段选择子，指向上面的段描述符表项。

#define __KERNEL_CS      (GDT_ENTRY_KERNEL_CS*8)
#define __KERNEL_DS      (GDT_ENTRY_KERNEL_DS*8)
#define __USER_DS      (GDT_ENTRY_DEFAULT_USER_DS*8 + 3)
#define __USER_CS      (GDT_ENTRY_DEFAULT_USER_CS*8 + 3)

通过分析，我们发现，所有的段的起始地址都是一样的，都是 0。所以，在 Linux 操作系统中，并没有使用到全部的分段功能。那分段是不是完全没有用处呢？分段可以做权限审核，例如用户态 DPL 是 3，内核态 DPL 是 0。当用户态试图访问内核态的时候，会因为权限不足而报错。 其实 Linux 倾向于另外一种从虚拟地址到物理地址的转换方式，称为分页（Paging）。对于物理内存，操作系统把它分成一块一块大小相同的页，这样更方便管理，例如有的内存页面长时间不用了，可以暂时写到硬盘上，称为换出。一旦需要的时候，再加载进来，叫作换入。这样可以扩大可用物理内存的大小，提高物理内存的利用率。

这个换入和换出都是以页为单位的。页面的大小一般为 4KB。为了能够定位和访问每个页，需要有个页表，保存每个页的起始地址，再加上在页内的偏移量，组成线性地址，就能对于内存中的每个位置进行访问了。

虚拟地址分为两部分，页号和页内偏移。页号作为页表的索引，页表包含物理页每页所在物理内存的基地址。这个基地址与页内偏移的组合就形成了物理内存地址。

32 位环境下，虚拟地址空间共 4GB。如果分成 4KB 一个页，那就是 1M 个页。每个页表项需要 4 个字节来存储，那么整个 4GB 空间的映射就需要 4MB 的内存来存储映射表。如果每个进程都有自己的映射表，100 个进程就需要 400MB 的内存。对于内核来讲，有点大了。

页表中所有页表项必须提前建好，并且要求是连续的。如果不连续，就没有办法通过虚拟地址里面的页号找到对应的页表项了。

那怎么办呢？我们可以试着将页表再分页，4G 的空间需要 4M 的页表来存储映射。我们把这 4M 分成 1K（1024）个 4K，每个 4K 又能放在一页里面，这样 1K 个 4K 就是 1K 个页，这 1K 个页也需要一个表进行管理，我们称为页目录表，这个页目录表里面有 1K 项，每项 4 个字节，页目录表大小也是 4K。

页目录有 1K 项，用 10 位就可以表示访问页目录的哪一项。这一项其实对应的是一整页的页表项，也即 4K 的页表项。每个页表项也是 4 个字节，因而一整页的页表项是 1K 个。再用 10 位就可以表示访问页表项的哪一项，页表项中的一项对应的就是一个页，是存放数据的页，这个页的大小是 4K，用 12 位可以定位这个页内的任何一个位置。

这样加起来正好 32 位，也就是用前 10 位定位到页目录表中的一项。将这一项对应的页表取出来共 1k 项，再用中间 10 位定位到页表中的一项，将这一项对应的存放数据的页取出来，再用最后 12 位定位到页中的具体位置访问数据。

你可能会问，如果这样的话，映射 4GB 地址空间就需要 4MB+4KB 的内存，这样不是更大了吗？当然如果页是满的，当时是更大了，但是，我们往往不会为一个进程分配那么多内存。

比如说，上面图中，我们假设只给这个进程分配了一个数据页。如果只使用页表，也需要完整的 1M 个页表项共 4M 的内存，但是如果使用了页目录，页目录需要 1K 个全部分配，占用内存 4K，但是里面只有一项使用了。到了页表项，只需要分配能够管理那个数据页的页表项页就可以了，也就是说，最多 4K，这样内存就节省多了。

当然对于 64 位的系统，两级肯定不够了，就变成了四级目录，分别是全局页目录项 PGD（Page Global Directory）、上层页目录项 PUD（Page Upper Directory）、中间页目录项 PMD（Page Middle Directory）和页表项 PTE（Page Table Entry）。

进程空间管理

物理内存管理

用户态内存映射

#define GDT_ENTRY_INIT(flags, base, limit) { { { \
  .a = ((limit) & 0xffff) | (((base) & 0xffff) << 16), \
  .b = (((base) & 0xff0000) >> 16) | (((flags) & 0xf0ff) << 8) | \
    ((limit) & 0xf0000) | ((base) & 0xff000000), \
  } } }

通过分析，我们发现，所有的段的起始地址都是一样的，都是 0。这算哪门子分段嘛！所以，在 Linux 操作系统中，并没有使用到全部的分段功能。那分段是不是完全没有用处呢？分段可以做权限审核，例如用户态 DPL 是 3，内核态 DPL 是 0。当用户态试图访问内核态的时候，会因为权限不足而报错。

其实 Linux 倾向于另外一种从虚拟地址到物理地址的转换方式，称为分页（Paging）。

对于物理内存，操作系统把它分成一块一块大小相同的页，这样更方便管理，例如有的内存页面长时间不用了，可以暂时写到硬盘上，称为换出。一旦需要的时候，再加载进来，叫作换入。这样可以扩大可用物理内存的大小，提高物理内存的利用率。

进程间通信概述

管道

在学 Linux 命令时就有管道在这个概念，比如下面这个命令

ps -ef  | -grep root | xargs kill -9

将上一个命令的输出作为下一个命令的输入，数据只能向一个方向流动；双方需要互相通信时，需要建立起两个管道。

管道有两种类型：匿名管道和命名管道。上面提到的命令中|表示的管道即匿名管道 pipe。用完即销毁，自动创建，自动销毁。

使用mkfifo显示创建的是命名管道 fifo，

mkfifo hello

hello即是管道名称，类型为p，就是pipe，接下来就可以在管道里写入东西，

# echo "hello world" > hello

光写入还不行，只有有另一个进程读取了内容才完成一次信息交换，才完成一次通信，

# cat < hello 
hello world

这种方式通信效率低，无法频繁通信。

消息队列

类似于日常沟通使用的邮件，有一定格式，有个收件列表，列表上的用户都可以反复在原邮件基础上回复，达到频繁交流的目的。这种模型就是消息队列模型。

共享内存

共享内存允许两个或多个进程共享一个给定的存储区，这一段存储区可以被两个或两个以上的进程映射至自身的地址空间中，一个进程写入共享内存的信息，可以被其他使用这个共享内存的进程，通过一个简单的内存读取错做读出，从而实现了进程间的通信。

每个进程都有自己独立的虚拟内存空间，不同进程的虚拟内存空间映射到不同的物理内存中去。这个进程访问 A 地址和另一个进程访问 A 地址，其实访问的是不同的物理内存地址，对于数据的增删查改互不影响。

但是，咱们是不是可以变通一下，拿出一块虚拟地址空间来，映射到相同的物理内存中。这样这个进程写入的东西，另外一个进程马上就能看到了，都不需要拷贝来拷贝去，传来传去。

使用shmget函数创建一个共享内存，

//key_t key:  唯一定位一个共享内存对象
//size_t size: 共享内存大小
//int flag: 如果是 IPC_CREAT 表示创建新的共享内存空间
int shmget(key_t key, size_t size, int flag);

创建完毕之后，我们可以通过 ipcs 命令查看这个共享内存。

#ipcs ­­--shmems
 
------ Shared Memory Segments ------ ­­­­­­­­
key        shmid    owner perms    bytes nattch status
0x00000000 19398656 marc  600    1048576 2      dest

进程通过shmat，就是attach的意思，将内存加载到自己虚拟地址空间某个位置。

//int shm_id:
//const void *addr: 加载的地址，通常设为 NULL，让内核选一个合适地址
//int flag:
void *shmat(int shm_id, const void *addr, int flag);

如果共享内存使用完毕，可以通过 shmdt 解除绑定，然后通过 shmctl，将 cmd 设置为 IPC_RMID，从而删除这个共享内存对象。

int shmdt(void *addr); 
int shmctl(int shm_id, int cmd, struct shmid_ds *buf);

共享内存的最大不足之处在于，由于多个进程对同一块内存区具有访问的权限，各个进程之间的同步问题显得尤为突出。必须控制同一时刻只有一个进程对共享内存区域写入数据，否则将造成数据的混乱。

信号量

如果两个进程同时向一个共享内存读写数据，很可能就会导致冲突。所以需要有一种保护机制，使得同一个共享资源同时只能被一个进程访问。在进程间通信机制中，信号量（Semaphore）就是用来实现进程间互斥与同步的。它其实是个计数器，只不过不是用来记录进程间通信数据的。

我们可以将信号量初始化为一个数值，来代表某种资源的总体数量。对于信号量来讲，会定义两种原子操作，一个是P 操作，我们称为申请资源操作。这个操作会申请将信号量的数值减去 N，表示这些数量被他申请使用了，其他人不能用了。另一个是V操作，我们称为归还资源操作，这个操作会申请将信号量加上 M，表示这些数量已经还给信号量了，其他人可以使用了。

所谓原子操作（Atom Operation）就是不可被中断的一个或一系列操作。

使用semget创建信号量，第一个参数表示唯一标识，第二个参数表示可以创建多少个信号量。

int semget(key_t key, int num_sems, int sem_flags);

接下来，我们需要初始化信号量的总的资源数量。通过semctl 函数，第一个参数 semid是这个信号量组的id，第二个参数 semnum 才是在这个信号量组中某个信号量的id，第三个参数是命令，如果是初始化，则用 SETVAL，第四个参数是一个 union。如果初始化，应该用里面的val设置资源总量。

int semctl(int semid, int semnum, int cmd, union semun args);
 
 
union semun
{
  int val;
  struct semid_ds *buf;
  unsigned short int *array;
  struct seminfo *__buf;
};

无论是 P 操作还是 V 操作，我们统一用 semop 函数。第一个参数还是信号量组的 id，一次可以操作多个信号量。第三个参数 numops 就是有多少个操作，第二个参数将这些操作放在一个数组中。

数组的每一项是一个 struct sembuf，里面的第一个成员是这个操作的对象是哪个信号量。第二个成员就是要对这个信号量做多少改变。如果 sem_op < 0，就请求 sem_op 的绝对值的资源。如果相应的资源数可以满足请求，则将该信号量的值减去 sem_op 的绝对值，函数成功返回。

当相应的资源数不能满足请求时，就要看sem_flg 了。如果把 sem_flg 设置为IPC_NOWAIT，也就是没有资源也不等待，则 semop 函数出错返回 EAGAIN。如果 sem_flg 没有指定IPC_NOWAIT，则进程挂起，直到当相应的资源数可以满足请求。若 sem_op > 0，表示进程归还相应的资源数，将 sem_op 的值加到信号量的值上。如果有进程正在休眠等待此信号量，则唤醒它们。

int semop(int semid, struct sembuf semoparray[], size_t  numops);
struct sembuf 
{
  short sem_num; // 信号量组中对应的序号，0～sem_nums-1
  short sem_op;  // 信号量值在一次操作中的改变量
  short sem_flg; // IPC_NOWAIT, SEM_UNDO
}

信号

以上提到的通信方式，都是常规状态下的工作模式，而信号一般是由错误产生的。

信号没有特别复杂的数据结构，就是用一个代号一样的数字。Linux 提供了几十种信号，分别代表不同的意义。信号之间依靠它们的值来区分。