操作系统理解（xv6）

xv6操作系统项目复习笔记

宗旨：只记大框架，不记细节，没有那么多的时间

一、xv6的页表是如何搭建的？

xv6这个项目中，虚拟地址用了39位（27位+12位（物理内存page偏移地址）），物理地址用了56位（44位（物理内存page首地址）+12位（物理内存page偏移地址））.

• 特别的，xv6中页表的实现是多级页表的形式，一个虚拟地址翻译为物理地址，需要内存管理单元（MMU）访问三次内存（每次访问一个page从对应位置获取下一个待访问page的地址）（页表缓存TLB会将虚拟地址到物理地址的映射记录到缓存中提升效率（处理器内部机制））,其中虚拟地址的27位(拆分成3个9位，分别指定MMU去page的哪个位置寻找下一个待访问page的地址)。
• 如果将2 ^ 39的虚拟地址全部映射到物理地址，页表的大小为1+512+512*512 = （1 + 2 ^ 9 +2^18）个page,相比直接一级映射节省空间，同时在实际应用中页表是按需构建，即哪些虚拟地址需要映射，才会增加变动页表大小。
  

二、内核页表

内核页表PHYSTOP以下虚拟地址和物理地址是一一对应的，顶端的Trampoline以及每个进程的内核栈（kalloc）不是一一对应的。
boot ROM:当你对主板上电，主板做的第一件事情就是运行存储在boot ROM中的代码，当boot完成之后，会跳转到地址0x80000000，操作系统需要确保那个地址有一些数据能够接着启动操作系统.
物理内存大小（RAM）:0x80000000到0x86400000,这个地址范围是100M,不过内核代码中PHYSTOP为0x80000000+12810241024,这个是有128M.(底下的图片是真实开发版的数据，而代码中的地址是qemu软件模拟的地址)

其中Kernel text和Kernel data先是直接映射到物理内存，另外其中的Trampoline以及进程的内核栈在虚拟地址顶部再重新映射了一次。（即两个虚拟地址映射到同一个物理地址，程序实际运行只用了顶部的虚拟地址）。（问题:kernel text和Kernel data中为什么有Trampoline和进程内核栈？）
答：Trampoline跳转页面是一段特定的汇编代码，保存在Kernel text部分（RX可读可执行）。进程的内核栈是通过kalloc从RAM中申请的1个page.内核页表中虚拟地址从KERNBASE到PHYSTOP之间全部都是直接映射，进程的内核栈申请到的地址也在这个区间里，内核是可以通过申请到的这个地址直接使用进程的内核栈的。（重新映射的原因：高效的上下文切换；内存保护；确保栈空间的独立性；理解起来麻烦，先不管）

三、进程地址空间和页表

从图中可以看到argument0-N代表的是argv中的每个参数字符串。address of argument N-0对应的是argv中的每个字符串在stack中的地址，argc为参数个数,return PC for main指明程序返回地址。

RISC-V和x86的区别

x86:复杂指令集（闭源）
RISC-V:精简指令集（开源）
ARM:精简指令集
简单来说：不同指令集有不同的汇编语言，不同处理器与不同的指令集配对，可以处理对应的汇编语言。x86处理器可以处理复杂指令汇编语言，RISC-V处理器可以处理RISC-V的汇编语言。

栈的结构

每调用一个函数，都会产生一个（stack frame）,栈是从高地址开始向低地址使用。

• Return address总是会出现在Stack Frame的第一位
• 指向前一个Stack Frame的指针也会出现在栈中的固定位置（即Return address底下的位置）
• sp寄存器：指向Stack的底部并代表了当前Stack Frame的位置
• fp寄存器：指向当前Stack Frame的顶部，可以用来获取Return address以及指向上一个stack frame的指针

Trap机制：用户空间到内核空间的转换

• 程序执行系统调用
• 程序出现了类似page fault、运算时除以0的错误
• 一个设备触发了中断使得当前程序运行需要响应内核设备驱动
  相关寄存器：
• STVEC:指向内核中处理trap的指令的起始地址（确保代码执行跳到trampoline位置）
• SEPC:在trap的过程中保存程序计数器的值（保存用户程序执行的位置）
• SSRATCH:保存了trapframe的虚拟地址
  trap从用户空间到内核空间的大概流程：
  ECALL指令执行：将程序寄存器的数值保存到SPEC中（保存用户程序的执行位置）；将STVEC寄存器中的地址加载到程序寄存器（代码执行位置跳到了trampoline）；
  uservec:交换a0寄存器和SSRATCH寄存器的值，此时trapframe的虚拟地址放到了a0寄存器中，此时把剩下保存用户程序执行的寄存器中的值保存到用户进程trapframe对应的内存区域。切换用户页表到内核页表，将sp寄存器指向对应进程的内核栈，接下来内核代码的运行将在进程对应的内核栈中运行。跳转到usertrap.
  usertrap:确定用户空间跳转到内核空间的原因（页面中断，系统调用，外部设备中断等等），并进行处理。
  usertrapret:细节不是那么重要了，遇到问题回去看代码就懂了。
  userret:程序计数器恢复为用户程序的程序计数器，继续执行最初的用户程序。

页面中断47

相关寄存器：
STVAL:保存出错的虚拟地址，或者是触发page fault的源。
SCAUSE ：保存发生trap的原因
页面中断主要用到的原因代码为13（load读取）和15（store 写入）

懒惰页面分配：用户进程申请内存时，先只增加可用空间大小，而不进行映射。这使得进程以为自己有了可用空间并对这些空间进行读写操作，但是由于没有进行内存映射，所以会发生页面中断，此时再对需要读写的页面进行映射，这样可以提高物理内存的空间利用率。不过，由于页面中断涉及用户空间和内核空间的切换，是有成本的。
Copy On Write Fork 在父进程中创建子进程，这里会涉及对父进程的内存的复制，Copy On Write Fork方案是创建的子进程的虚拟内存映射到和父进程一样的物理内存（子进程与父进程共享物理内存），仅当子进程需要访问修改共享物理内存时，为子进程申请独立的页面。这样子可以节省重复从堆区申请大量冗余的页面。
内存映射：为了降低外接存储设备的访问频率，可以将打开的文件的内存映射到物理内存的某一区域，此时可以通过访问物理内存来读取或修改原文件中的信息。

文件系统

xv6文件系统布局(存储在硬盘中)
1个block：1024字节
block0: 无用或者用于boot sector(启动操作系统)
block1: super block, 它描述了文件系统。它可能包含磁盘上有多少个block共同构成了文件系统这样的信息。
block2 - block31: log信息
block32 - block45: innode信息（单个innode是64字节）一个block可以存储16个innode
block46: bitmap block,记录对应位置data block是否空闲
其余block: 存储文件内容信息data block
xv6中一个文件的最大大小如何确定？
一个innode是64字节，其中有13*4 = 52个字节(13个block编号，每个编号占4个字节32位，即xv6最大可以索引2^32个block)指出了文件内容存储在哪个data block,其中前12个block编号的数值直接对应的就是存储文件数据的block,最后一个block是一个一级间接块（indirect block），这个block指向的块中又可以存储256个块号。即一个文件最大大小是（12+256）即268个data block.

硬盘布局：
[ boot block | super block | log | inode blocks | free bit map | data blocks]
相关代码：xv6中只有1000个block

// super block describes the disk layout:
struct superblock {uint magic;        // Must be FSMAGICuint size;         // Size of file system image (blocks)uint nblocks;      // Number of data blocksuint ninodes;      // Number of inodes.uint nlog;         // Number of log blocksuint logstart;     // Block number of first log blockuint inodestart;   // Block number of first inode blockuint bmapstart;    // Block number of first free map block
};
// On-disk inode structure
struct dinode {short type;           // File type short major;          // Major device number (T_DEVICE only)short minor;          // Minor device number (T_DEVICE only)short nlink;          // Number of links to inode in file system uint size;            // Size of file (bytes) uint addrs[NDIRECT+2];   // Data block addresses 
};

对xv6文件系统的理解：
从用户端理解：
文件名构成：根目录/子目录/当前目录/当前文件名。
dir和file 在底层都是一个数据文件，一个数据文件的信息由索引节点标识和内部数据组成，索引节点标识中给出了数据在硬盘中的存储区域，数据量大小，数据文件类型（dir还是file）.dir数据文件中存储的是下一级dir和下一级file（由对应的Inode number（索引节点号码）和name组成）,file数据文件中保存的是文本或代码。
打开文件过程中，会从根目录数据文件中通过搜索子目录名获取到子目录对应的inode number,接着根据inode number获取到子目录的数据文件，再通过该数据文件获取到当前目录的inode number…，进而得到当前文件名对应得innode number，就可以获取到当前文件的信息了，这就是文件系统读取一个文件中信息的过程。
硬链接：硬链接是指在硬盘中，一个数据文件对应一个 inode（索引节点）。在日常使用中，我们可能希望不同的文件名指向同一个数据文件。例如，当我们复制并重命名一个文件时，操作系统并不会为新文件申请一个新的 inode 或在硬盘上创建新的数据区域。其底层实现过程如下：首先获取旧文件的 inode，然后找到新文件名对应目录项的 inode。接着，将旧文件的 inode number（即 inode 索引号）和新文件的名称写入新文件目录项的数据文件中。这样，在新文件的目录项中新增了一条 entry，包含 inode number 和文件名，从而实现了硬链接。通过这种方式，两个文件名指向同一数据文件，共享相同的 inode。
软链接：软链接则是创建一个新的文件名，并为其分配一个新的 inode。在这个新的 inode 中，存储的是旧文件的路径（即文件名）。软链接本质上是一个指向旧文件的路径引用，而不是直接指向数据块。因此，软链接文件可以指向任何文件，包括不存在的文件，而硬链接只能指向已存在的文件，并且硬链接之间不会区分原文件和链接文件。
硬链接：多个文件名（目录项）指向同一个数据块，文件内容共享。
软链接：新文件名指向原文件的路径，可以跨文件系统，且可以指向不存在的文件。
缓存区高速缓存：频繁从磁盘中读取数据的过程非常慢，设定高速缓存区可以将磁盘中的某一个block对应到一个buffer空间中，在buffer中读写数据完成后再写入磁盘，有效提高程序执行效率。
日志：防止特殊情况，比如断电等特殊情况，使得写入磁盘的过程出现中断，可能会使得inode节点的信息与数据块的信息不对应，造成文件存储错误。日志的简单流程就是先将要写入的数据写入到log block中，等到所有的文件数据写完之后，在日志中标记写入完成，之后再将要写入inode block和data block中的数据从log block中迁移过去。（细节有需要的时候再去扣，现在没有必要）

内存映射实验

实现mmap函数（内存映射）和munmap（解除映射）函数
案例：mmap用于将一个内存映射到进程的虚拟地址空间中，通过mmap，程序可以在内存中直接访问文件的内容，而无需使用传统的 read 或 write 系统调用来逐字节地进行文件操作。

void *mmap(void *addr, size_t length, int prot, int flags,int fd, off_t offset);

在xv6中的底层实现：
懒加载：文件映射到进程虚拟地址空间中，最开始只会将进程虚拟地址空间增加length,但是这length空间并没有在进程页表中映射。当进程访问（读取或写入）这部分地址空间时才会利用页面中断机制，对这部分内存进行映射。
解除映射过程中，如果修改在进程地址空间中修改过的内容需要写回文件，在解除映射的时候将虚拟内存中的内容写入到文件当中去。
这样就实现了先将文件中的内容按需映射到进程虚拟地址空间中，然后在进程的虚拟地址空间中对文件内容进行读取更改，解除映射的时候再将文件内容写回到文件当中去（写回硬盘）。这样就避免了频繁反复从硬盘读取写入内容，可以由更好的性能。

Lock实验

临界条件：critical section
1.解决一个锁争用问题：
问题背景：多个进程在不断申请释放内存，这使得内核需要不断调用kalloc以及kfree函数，由于管理物理内存释放调用的链表用一个自旋锁进行保护，当不同CPU中的进程在一个时间段都要访问内存管理链表时，会发生锁争用等待，降低性能。
解决方案：将所有可申请的内存空间分配给不同的CPU，每个CPU针对一部分空间使用一个自旋锁进行保护，这样就可以每个CPU的进程申请释放内存互不干扰，更好提升性能。
2.对于buffer cache的理解：
操作系统缓存区命中：指在操作系统的缓存机制中，所请求的数据已经存在于缓存区内，操作系统能够直接从缓存中获取数据，而无需再次访问底层的存储设备（如硬盘、网络等）。缓存区命中是缓存系统高效工作的一个重要指标，能够显著提高数据访问速度和系统性能。
xv6中buffer cache是用一个双向链表连接了一组buffer数据块。当进程要从硬盘中读取一个block，并不是直接从硬盘读写，而是先为这个block在内存中申请一个buffer缓冲块，将硬盘中的内容读取到buffer数据块中，数据会暂时保存在这个数据块中。如果进程频繁读取就不用从硬盘中读取而是直接从缓冲块中读取，提高了性能，写入也是先写入缓存块再在合适的时间将所有数据同一写回硬盘，提高了性能。

struct logheader {int n;int block[LOGSIZE];
};
日志块中有一个block数组记录了日志块中保留的数据副本最后要写入到哪个数据块中

哪些情况要用锁？
一段内存共享，不同的进程同一时间进行读写;一段代码要具备原子性，如果被不同进程交错执行，会引发错误。
加锁限制了并发性，也限制了性能。

死锁情况：




自旋锁的实现
__sync_lock_test_and_set是一个原子操作，通过向锁的标志位写入1，并获取锁之前的标志位。如果之前的标志位为0，则现在成功获取了锁，如果之前的标志为1,则锁被占用，进入循环。原子操作为了防止一个进程释放锁，另外两个进程同时发现锁被释放，此时会发生两个CPU进程同时获取锁，导致错误。原子操作确保了一次只能有一个CPU进程访问锁的标志位。

void
acquire(struct spinlock *lk)
{push_off(); // disable interrupts to avoid deadlock.if(holding(lk))panic("acquire");// On RISC-V, sync_lock_test_and_set turns into an atomic swap://   a5 = 1//   s1 = &lk->locked//   amoswap.w.aq a5, a5, (s1)while(__sync_lock_test_and_set(&lk->locked, 1) != 0);// Tell the C compiler and the processor to not move loads or stores// past this point, to ensure that the critical section's memory// references happen strictly after the lock is acquired.// On RISC-V, this emits a fence instruction.__sync_synchronize();// Record info about lock acquisition for holding() and debugging.lk->cpu = mycpu();
}

xv6多核运行的理解，进程，线程调度

整体理解：
1.定时器中断，会使用户进程A从用户空间进入到内核空间kernel，此时程序函数调用执行在进程的内核栈，这里也可以说是正在执行内核线程。
2.从内核线程A通过swtch函数跳到调度器线程，这个过程中将进程A内核线程的相关寄存器保存到进程的context中，并从调度器线程即cpu的context取出数据到相关寄存器，此时程序就进入到了scheduler（）函数中（死循环寻找状态为runable的进程），找到可以运行的进程B，通过swtch函数从调度器线程跳入到进程B的内核线程，这个过程将调度器线程的寄存器存入到cpu的context中，然后将进程B的context中的数据取出到相关寄存器，此时程序就执行到了进程B的内核线程位置（这个位置也是之前进程B发生调度的位置），之后从内核空间返回到用户空间中执行进程B在用户空间的程序。
3.多核cpu是指多个处理器并行运行，执行相同的代码。不同cpu执行的区别在于，不同cpu调度器线程使用的stack是不同的。程序中会通过从cpu的tp寄存器中获取cpuid,来决定不同cpu执行哪部分代码。
4.在内核空间之所以使用了进程A的内核线程，进程B的内核线程，调度器线程。是因为线程使用的内存空间是一致共用的，区别仅仅是不同线程执行程序的位置（保留在context中）不同，不同线程执行程序调用的堆栈地址不同。而不同进程的用户空间是不共享的，具有独立的虚拟页表，独立申请释放可用空间。
5.xv6中在进程的用户空间，并没有实现线程，按照我的理解，实现线程的步骤大概是：就是为每个线程设定独立的栈空间，设定独立的context存储相关寄存器（ra,sp等等），实现一个线程swtch函数实现不同线程的寄存器切换。这样就可以在不同线程之间切换。

1.每个cpu都会运行下方这三段程序，多核运行就是并行运行。
2.每个cpu都会有自己的cpuid，每个cpu通过查看自己的tp寄存器（tp寄存器在cpu内部，用作cpu标识）就可以知道自己的编号，同时也就知道了初始化main函数中哪部分程序自己不能运行。
3.初始化部分，为每个CPU设置了调度器线程，以及调度器线程运行的栈空间，调度器线程是进程调度之间的重要一环。（线程的标志就是有自己独立的context,记录自己的栈空间，函数返回地址，以及相关其他寄存器数据，这些决定了线程运行到了哪个位置，等再次调度时可以继续运行，同时不同线程是共享内存空间，内核中的线程共享内核页表对应的空间，用户进程中的线程共享用户进程的用户页表空间）

//汇编语言写成的启动程序# qemu -kernel loads the kernel at 0x80000000        //qemu内核将xv6内核加载到物理地址为0x80000000的内存中，地址范围0x0:0x80000000包含I/O设备# and causes each hart (i.e. CPU) to jump there.     //每个 RISC-V 核心（Hart，代表一个处理器）会跳转到 0x80000000 地址，开始执行内核代码。# kernel.ld causes the following code to             //kernel.ld 是链接器脚本，指定了内核代码将被放置在物理地址 0x80000000 处。# be placed at 0x80000000.
.section .text //指定接下来的代码是文本段（程序代码）
.global _entry // 声明 _entry 为全局符号，意味着它是程序的入口点，供链接器或加载器识别。
_entry: //代码的入口标签# set up a stack for C.     //设置一个栈区运行C代码# stack0 is declared in start.c, # with a 4096-byte stack per CPU.# sp = stack0 + (hartid * 4096)//stack0 在 start.c 文件中声明，为每个 CPU（每个 Hart）分配了 4096 字节的栈空间。这里根据 hartid（每个 CPU 的 ID）来计算每个核心的栈空间。la sp, stack0li a0, 1024*4 // 将 a0 寄存器设置为 4096csrr a1, mhartid //将当前 CPU 的 ID（mhartid）读取到寄存器 a1 中。mhartid 是 RISC-V 的一个控制寄存器，表示当前核心的编号addi a1, a1, 1   //将 a1 寄存器中的值加 1，用来计算每个 CPU 的栈地址偏移（每个 CPU 的栈空间是独立的）mul a0, a0, a1   add sp, sp, a0# jump to start() in start.ccall start
spin:j spin

void
start()
{// set M Previous Privilege mode to Supervisor, for mret.unsigned long x = r_mstatus();x &= ~MSTATUS_MPP_MASK;x |= MSTATUS_MPP_S;w_mstatus(x);// set M Exception Program Counter to main, for mret.// requires gcc -mcmodel=medanyw_mepc((uint64)main);// disable paging for now.w_satp(0);//禁用虚拟页表// delegate all interrupts and exceptions to supervisor mode.w_medeleg(0xffff);w_mideleg(0xffff);w_sie(r_sie() | SIE_SEIE | SIE_STIE | SIE_SSIE);// configure Physical Memory Protection to give supervisor mode// access to all of physical memory.w_pmpaddr0(0x3fffffffffffffull);w_pmpcfg0(0xf);// ask for clock interrupts.timerinit();// keep each CPU's hartid in its tp register, for cpuid().int id = r_mhartid();w_tp(id);//mhartid寄存器读取较麻烦，tp寄存器读取较方便// switch to supervisor mode and jump to main().asm volatile("mret");
}

volatile static int started = 0;// start() jumps here in supervisor mode on all CPUs.
void
main()
{if(cpuid() == 0){consoleinit();printfinit();printf("\n");printf("xv6 kernel is booting\n");printf("\n");kinit();         // physical page allocatorkvminit();       // create kernel page table 创建内核页表(完成了设备部分和RAM部分的直接映射以及虚拟地址顶部的Trampoline以及进程内核栈的映射)kvminithart();   // turn on paging 安装内核页表，它将根页表页的物理地址写入寄存器satp。之后，CPU将使用内核页表转换地址。由于内核使用标识映射，下一条指令的当前虚拟地址将映射到正确的物理内存地址。procinit();      // process table 每个进程分配一个内核栈。它将每个栈映射到KSTACK生成的虚拟地址，这为无效的栈保护页面留下了空间。trapinit();      // trap vectorstrapinithart();  // install kernel trap vectorplicinit();      // set up interrupt controllerplicinithart();  // ask PLIC for device interruptsbinit();         // buffer cacheiinit();         // inode tablefileinit();      // file tablevirtio_disk_init(); // emulated hard diskuserinit();      // first user process__sync_synchronize();started = 1;} else {while(started == 0);__sync_synchronize();printf("hart %d starting\n", cpuid());kvminithart();    // turn on paging kvmmap将映射的PTE添加到内核页表中，对kvminithart的调用将内核页表重新加载到satp中，以便硬件知道新的PTE。trapinithart();   // install kernel trap vectorplicinithart();   // ask PLIC for device interrupts}scheduler();        
}

从上面的代码可以看出，每个cpu执行到main函数最后都会执行下方的 scheduler()函数，这里面是一个死循环，不断进行进程调用。每个cpu结构体中proc代表了在当前cpu中执行的进程，context存储了cpu调度器进程切换到其他进程内核线程前的寄存器（包括调度器线程的ra,sp等等），因为一段时间后程序还要回来进行调度其他进程的。

// Per-CPU state.
struct cpu {struct proc *proc;          // The process running on this cpu, or null.struct context context;     // swtch() here to enter scheduler().int noff;                   // Depth of push_off() nesting.int intena;                 // Were interrupts enabled before push_off()?
};
// Per-CPU process scheduler.
// Each CPU calls scheduler() after setting itself up.
// Scheduler never returns.  It loops, doing:
//  - choose a process to run.
//  - swtch to start running that process.
//  - eventually that process transfers control
//    via swtch back to the scheduler.
void
scheduler(void)
{struct proc *p;struct cpu *c = mycpu();c->proc = 0;for(;;){// The most recent process to run may have had interrupts// turned off; enable them to avoid a deadlock if all// processes are waiting.intr_on();int found = 0;for(p = proc; p < &proc[NPROC]; p++) {acquire(&p->lock);if(p->state == RUNNABLE) {// Switch to chosen process.  It is the process's job// to release its lock and then reacquire it// before jumping back to us.p->state = RUNNING;c->proc = p;swtch(&c->context, &p->context);// Process is done running for now.// It should have changed its p->state before coming back.c->proc = 0;found = 1;}release(&p->lock);}if(found == 0) {// nothing to run; stop running on this core until an interrupt.intr_on();asm volatile("wfi");}}
}

swtch函数：从当前线程转到另外的线程中执行。在xv6中主要涉及：从进程内核线程跳转到cpu调度器线程；从cpu调度器线程跳转到其他进程的内核线程。

# Context switch
#
#   void swtch(struct context *old, struct context *new);
# 
# Save current registers in old. Load from new.	
.globl swtch
swtch:sd ra, 0(a0)sd sp, 8(a0)sd s0, 16(a0)sd s1, 24(a0)sd s2, 32(a0)sd s3, 40(a0)sd s4, 48(a0)sd s5, 56(a0)sd s6, 64(a0)sd s7, 72(a0)sd s8, 80(a0)sd s9, 88(a0)sd s10, 96(a0)sd s11, 104(a0)ld ra, 0(a1)ld sp, 8(a1)ld s0, 16(a1)ld s1, 24(a1)ld s2, 32(a1)ld s3, 40(a1)ld s4, 48(a1)ld s5, 56(a1)ld s6, 64(a1)ld s7, 72(a1)ld s8, 80(a1)ld s9, 88(a1)ld s10, 96(a1)ld s11, 104(a1)ret

睡眠锁的实现

解决lost-wakeup问题：
这个问题比较复杂，忘记了就再回去看一下教程。
解决条件：

• 调用sleep时需要持有condition lock，这样sleep函数才能知道相应的锁。（确保持有睡眠锁的一方可以开始释放睡眠锁）
• sleep函数只有在获取到进程的锁p->lock之后，才能释放condition lock。
• wakeup需要同时持有两个锁才能查看进程。（wakeup只有当另一个未持有锁的进程设置成sleep状态之后，释放进程锁后菜才能唤醒该进程）

void
acquiresleep(struct sleeplock *lk)
{acquire(&lk->lk);//必须先获取自旋锁while (lk->locked) {sleep(lk, &lk->lk);//在sleep中释放自旋锁，如果不释放，另一个持有锁的进程就无法释放睡眠锁}lk->locked = 1;lk->pid = myproc()->pid;release(&lk->lk);
}
void
releasesleep(struct sleeplock *lk)
{acquire(&lk->lk);//另一个进程在sleep中释放了自旋锁，这里才能获取lk->locked = 0;lk->pid = 0;wakeup(lk);release(&lk->lk);
}
void
void
sleep(void *chan, struct spinlock *lk)
{struct proc *p = myproc();// Must acquire p->lock in order to// change p->state and then call sched.// Once we hold p->lock, we can be// guaranteed that we won't miss any wakeup// (wakeup locks p->lock),// so it's okay to release lk.acquire(&p->lock);  //DOC: sleeplock1release(lk);// Go to sleep.p->chan = chan;p->state = SLEEPING;sched();// Tidy up.p->chan = 0;// Reacquire original lock.release(&p->lock);acquire(lk);
}
wakeup(void *chan)
{struct proc *p;for(p = proc; p < &proc[NPROC]; p++) {if(p != myproc()){acquire(&p->lock);if(p->state == SLEEPING && p->chan == chan) {//查看是不是这个进程在睡眠等待事件发生p->state = RUNNABLE;}release(&p->lock);}}
}

如何理解父进程与子进程的执行

1.在用户空间中，一个进程（father）调用fork函数创建子进程(son)，子进程会完全复制父进程的一切，包括页表内容，trapframe中的内容，stack中的内容，堆区的内容，代码段，数据段的内容。即子进程可以看作是一个父进程的副本。
2.father进程调用fork系统调用进入内核空间，将用户空间运行的相关的寄存器全部保存到了trapframe中，而son进程则完全复制了trapframe中的内容，也就是说当son进程在内核中被调度并返回到son进程用户空间时，程序执行的位置和father进程程序执行的位置是一样的，即father进程和son进程在用户空间都运行到了pid = fork()；这段代码。
3.唯一不同的点是fork函数中对子进程中np->trapframe->a0的值赋值为0，而np->trapframe->a0的值对应的则是内核调用的返回值，即pid的值，此时father进程的pid的值为大于0的pid数值，而子进程的pid数值为0.通过这一点就能够很好的区分父进程执行哪一段代码，子进程执行哪一段代码。对于没有pid判断语句的代码区域，是父进程和子进程都会执行的区域。
4.这就解释了在用户空间中pid判断语句的代码。
5.一个进程要释放，先运行exit,再运行wait,wait函数中才是真正释放进程页表等相关内容，exit只是释放了相关文件引用，并将进程状态设置为ZOMBIE，wait函数检测到ZOMBIE只会则会回收该进程的一切。（其中也用到了sleep_wakeup机制）

int pid = fork();
if(pid > 0) {printf("parent: child=%d\n", pid);pid = wait((int *) 0);printf("child %d is done\n", pid);
} else if(pid == 0) {printf("child: exiting\n");exit(0);
} else {printf("fork error\n");
}
int
fork(void)
{int i, pid;struct proc *np;struct proc *p = myproc();//获取父进程信息// Allocate process.//分配进程if((np = allocproc()) == 0){return -1;//内存申请失败}// Copy user memory from parent to child.//复制父进程页表信息到子进程中，父子进程公用页表信息if(uvmcopy(p->pagetable, np->pagetable, p->sz) < 0){freeproc(np);release(&np->lock);return -1;}np->sz = p->sz;// copy saved user registers.*(np->trapframe) = *(p->trapframe);//公用寄存器信息// Cause fork to return 0 in the child.np->trapframe->a0 = 0; //a0寄存器为0// increment reference counts on open file descriptors. //文件描述符计数for(i = 0; i < NOFILE; i++)if(p->ofile[i])np->ofile[i] = filedup(p->ofile[i]);//子进程复制父进程文件句柄np->cwd = idup(p->cwd);//复制当前目录safestrcpy(np->name, p->name, sizeof(p->name));//添加一句话将跟踪掩码从父进程复制到子进程np->tracemask = p->tracemask;pid = np->pid;release(&np->lock);acquire(&wait_lock);np->parent = p;release(&wait_lock);acquire(&np->lock);np->state = RUNNABLE;release(&np->lock);return pid;
}

中断

PLIC会管理外设中断。会先通知所有cpu发生了中断，只会有一个cpu接收中断，之后PLIC就会将中断的具体情况发送给对应CPU，如果当前所有CPU都在处理中断，那么PLIC会暂时将中断信息保留下来，等到有CPU空闲时才会处理中断。CPU核处理完中断之后，CPU会通知PLIC，PLIC将不再保存中断的信息。

进程结束

exit(0)只是关闭了进程的相关文件fd，并将进程的状态修改为ZOMBE
wait(0)是用来释放进程的内存的。
释放进程exit和wait是需要同时调用的，一个都少不来。
exit的传入参数指出了当前进程结束是正常结束0还是说异常计数-1
wait(&status)可以将exit的传入参数保存到变量status中去，这样就知道进程是如何结束掉的了，可以用来debug.这下搞清楚了。wait传入0参数表明不关心进程是如何结束的。主动调用exit(0)是一个比较好的习惯。C语言当程序执行完之后也会默认自动调用exit关闭相关文件描述符。子进程的close(fd)不管也行的，但是为了维护者方便，子进程中额外使用的文件描述符最好使用close(fd),方便维护者理解代码。