John_Snowww-CSDN博客

原创 6.s081通关小结

正巧彼时我又发现了一本名为《30天自制操作系统》的书籍，这仿佛成了另一缕穿透迷雾的光。再然后就到了pgtbl。说实话这个lab给我带来的感觉是全系列最难，要考虑的点实在太多了，重重陷阱让我一次又一次地跌倒。每个lab都带走了我数不清的脑细胞，又不断巩固着我的道心。那个时候感觉每一步前进都是沉重的——困难的不是解决问题的过程，而是寻找着手点。但有了lab1的拷打，我慢慢找到了那种可意会不可言传的解题感觉，理清思路然后完成lab变成了一个自然而然的过程。有了这次的经历，我眼中的s081慢慢褪去了神秘的面纱。

2024-06-01 10:26:32 460 2

原创 6.824/6.5840 的Debugging by Pretty Printing配置

我的Python解释器目录在/usr/bin，目录的后缀/xxx是把xxx.py文件复制到这个文件夹中并且改名为xxx。我这里就是把dtest.py复制到了/usr/bin后改名为dtest。4.修改当前需要执行的文件的权限 chmod +x xxx.py。如果你没有遇到pip的问题，成功安装好了rich库，进行下一步。如果你的WSL2没有安装过Python的库，一般还会报错。这句命令的意思是为xxx.py这个文件添加可执行权限。如果你也碰到了类似的问题，把上述语句改为。然后我发现我的pip命令报错了。

2024-07-09 17:00:19 438

原创将克隆到本地的6.824项目上传到自己的github

git pull <自己创建的远程分支名称> <从自己的仓库哪条分支拉取> --allow-unrelated-histories。为了尝试把远程仓库里的内容拉取到本地，我可谓是绞尽脑汁。最后重要试出了正确的格式。要先把仓库里的README拉取到本地才行，然后在把本地文件夹一起提交到远程仓库里。由于github可以给自己的主分支改名了，我这次是勾选了创建README文件。git push <刚才创建的远程分支名> <本地分支名>:<远程分支名>将远程仓库的内容成功拉取到本地后，就是经典三板斧操作了。

2024-06-09 23:20:34 630

原创 Virtual Memory Primitives for User Program翻译

传统上，内存管理单元（MMUS）被操作系统用于实现磁盘分页的虚拟内存。一些操作系统允许用户程序指定页面的保护级别（不可访问、只读、读写），并允许用户程序处理保护违规。但这些机制不总是坚固、高效，也不总是与应用程序的需求匹配。我们调查了几种使用页面保护技术的用户级算法，并分析了它们的共同特点，试图回答以下问题：“操作系统应该为用户进程提供什么虚拟内存基元，当前的操作系统如何提供它们？

2024-06-09 22:58:39 1014

原创 CSAPP Lab01——Data Lab完成思路

既然对x的每位进行判断有困难，那还是老样子直接考虑数字这个整体。由于题目提供的运算符也不多，所以x的正负性成了可以拿来解题的性质。注意到一点，只要x不为0，那x的相反数符号位就和x的符号位是不同的。从正负性和符号位着手这题就很容易解决了。

2024-06-09 22:54:20 953

原创 CSAPP Lab02——Bomb Lab完成思路详解

可使用命令 touch answers.txt 新建名为answers的.txt文件，将所有拆弹密码写入该文件，然后用命令 ./bomb answers.txt 运行bomb可执行文件（之前的每一关调试结束后，也可以将新的拆弹密码写入.txt文件，用这个方法验证是否爆炸，就不用每次重复输入之前关卡的拆弹密码了）。

2024-06-04 23:31:05 1054

原创 CSAPP Lab03——Attack Lab

这次的要求看上去和touch2差不多，不过它要求的是传递指向cookie的指针到touch3里面。所以这个lab需要完成的就是两大点：把cookie的地址赋给edi传给touch3，注意这个地址不能放在getbuf开辟的缓冲区里，否则可能被hexmatch和strncmp覆盖。跳转到存放汇编代码的首地址跳转到touch3

2024-06-04 23:15:50 1114

原创 CSAPP Lab04——Cache Lab大师手笔，匠心制作

最后得到的“cache simulator”模式如下：cache看成一个二维数组，组Si 里面的每一行因为不考虑数据位就可以看成是一个结构体元素，有几行就可以看成有几个结构体元素，相当于做了降维处理。写到题解的后半部分的时候，我才发现其实把cache也声明成一个结构体(S,E都是它的成员)才是一个最好的选择。

2024-06-03 12:47:50 1678

原创 CSAPP Lab05——Performance Lab完成思路

这次由于被测试的矩阵大小从32×32到1024×1024，所以再笼统地把分块定为8×8肯定是不妥当的。同时本次lab没有给出cache的大小，所以我测试了8×8、16×16、32×32等不同尺度的分块，最终发现32×32的分块尺度是最佳的。

2024-06-03 11:28:10 694

原创 CSAPP Lab06——Shell Lab通关思路

上来就遇到了些小问题：①本来想看看“tshref”支持的命令，结果命令居然被拒绝执行了，显示“。然后又试了下“./sdriver.pl -h”这个命令，也是报错“我还以为是用户权限的问题，试了下切到root，结果还是不能执行。最后查看了下文件，发现除了自己编译的文件，其他文件都是“rw-r--r--”。下面是GPT对文件默认权限问题的回答。②书上P239，关于子进程和父进程对各自内存里的内容进行操作后的结果。③在正式进行实验之前，还得正式了解一番waitpid函数。

2024-06-02 23:49:03 1063

原创 CSAPP Lab07——Malloc Lab完成思路

这也是浪费最多时间的一部分。3.3.2、next block已分配，或者两块大小和blocksize_Sumaszie：对下一块使用place()

2024-06-02 23:23:54 1062

原创 CSAPP Lab08——Proxy Lab完成思路

Q：计算机网络中port的作用是什么？A：在计算机网络中，"port"（端口）是用于标识网络通信中的特定应用程序或服务的数字标识符。端口是网络通信的重要组成部分，它允许多个应用程序在同一台计算机上共享网络连接，并确保正确地将数据传递给目标应用程序。端口通常与 IP 地址结合使用，构成了网络通信中的目标地址。IP 地址用于标识网络中的设备，而端口则用于标识设备上的具体应用程序或服务。

2024-06-01 10:54:46 1325

原创 2020 6.s081——Lab1：Xv6 and Unix utilities梦开始的地方

首先透彻理解Lecture01的知识很是重要①“wait(int *status)”函数用于等待子进程的终止，它的参数是一个指向整数的指针（通常是 int * 类型），并且通常用来存储子进程的终止状态。这里“0”意思是将指针赋值为NULL，表示不关心子进程的退出状态信息，这意味着不打算获取子进程的终止状态。如果传递一个非NULL的指针给wait(int *status)函数，它将用来存储子进程的退出状态信息，以便可以检查子进程的退出状态，例如子进程是正常终止还是出错等。

2024-05-31 23:06:28 1413

原创 2020 6.s081——Lab2：system calls

在完成这个lab的时候，我突然想到一个问题，用户空间中使用的函数是trace(int n)，但是内核空间使用的却是sys_trace(void)，那用户空间传递的这个n到底是怎么被内核接收到的呢？我们按照hints查看sys_fstat() （kernel/sysfile.c）和filestat() （ kernel/file.c ），可以发现一条及其重要的注释。④在user.h中定义函数trace(int)，在usys.pl中设置sys_trace的调用入口。读懂了实验要求，就可以着手实验部分了。

2024-05-31 22:45:01 926

原创 2020 6.s081——Lab3：page tables坐牢日记

在sbrk()真正的实现函数growproc中，如果空间是增长的，那需要进行的映射是“把用户页表新增长的空间映射到内核页表中”，而不是从头开始映射一遍，不然就会出现下列“panic: remap”的问题。因为在内核页表中0~oldsize的部分已经是用户页表的内容了，但是oldsize~newsize的部分确实空的，所以需要映射的只有这一小块。同时，涉及到某页表内容(trapframe、kstack)时，给它们给配的空间默认也是一个页表的初始大小，故涉及空间大小时参数也是PGSIZE。

2024-05-30 20:34:08 1203

原创 2020 6.s081——Lab4：traps

本 lab 的直接要求时实现 sigalarm，什么意思呢？就是当进程调用 sigalarm 时，就会按照 CPU 时钟来定时的执行某一个函数。比如，test0调用了 sigalarm(2, func)，那该进程就会每隔 2 个 CPU 时钟调用一次 func。

2024-05-30 17:23:20 989

原创 2020 6.s081——Lab5：Lazy page allocation

我们在walkaddr()内部进行和usertrap相似的操作，区别是在walkaddr()中我们操作的对象是传入的va，而非usertrap中的stval。发现这个函数内部倒是没报错，是内核出了问题。接下来就是处理最麻烦的部分了，也就是hint4：处理这种情形：进程从sbrk()向系统调用（如read或write）传递有效地址，但尚未分配该地址的内存。在前面搞多了注释“panic：xxx”的操作之后，我下意识地就是来一手掩耳盗铃，直接把上述panic给注释了，发现没有效果才开始认真思考到底是什么原因。

2024-05-29 17:08:07 998

原创 2020 6.s081——Lab6：Copy-on-Write Fork for xv6踩坑历程

只有当子进程尝试写入共享的页面时，COW机制才会触发，为子进程创建新的物理页面，并将子进程的level2页表中相应的PTE更新为指向新分配的物理页面。因此，子进程的level2页表中的PTE实际上指向父进程的level1页表，而不是直接指向父进程的物理页面。在COW fork()过程中，子进程的level2层次的页表是与父进程的level2层次的页表相同的。页面，那么写操作会触发页面错误，操作系统会通过页错误处理机制来创建该页面的副本，并将副本映射到写操作发生的进程的地址空间中。

2024-05-29 16:37:01 1020

原创 2020 6.s081——Lab7：Multithreading完成思路

应该是有史以来最轻松的一个lab，大部分时间都花在了看实验说明给出的阅读材料和代码阅读上。真正着手完成代码的时间总共也就个把小时。上周过于摆烂，没怎么学进去。

2024-05-27 23:21:10 1202

原创 2020 6.s081——Lab8：Locks完成思路

这个lab的思路和multithread那个是一样的，都是利用哈希桶来细化锁的颗粒从而达到提高并发的效果。

2024-05-27 18:59:37 778

原创 2020 6.s081——Lab9：File system

在跟踪符号链接时需要额外考虑到符号链接的目标可能还是符号链接, 此时需要递归的去跟踪目标链接直至得到真正的文件。

2024-05-26 22:16:04 827 1

原创 2020 6.s081——Lab10：Mmap完成记录

它可能与文件的长度不同。内存映射，简而言之就是将用户空间的一段内存区域映射到内核空间，映射成功后，用户对这段内存区域的修改可以直接反映到内核空间，相反，内核空间对这段区域的修改也直接反映用户空间。这种情况可能会增加系统的内存开销，因为每个进程都会分配自己的物理页面来映射同一个文件，但也有助于提高系统的安全性，因为各个进程之间不会共享物理页面，从而避免了可能的安全隐患。映射的处理方式上，通常情况下，操作系统会在内核中维护一张页面表，将不同进程的虚拟地址映射到相同的物理页面上，以实现对文件的共享访问。

2024-05-26 21:10:47 1115

原创 2020 6.s081——Lab11：Networking踩坑之旅

不同于发送模型中 mbuf 的空间需要我们自己分配，在接收模型中，mbufs 的每一个元素对应空间都已经被分配好了，用于存放接收到的报文。，E1000可以在其中写入接收到的数据包。除了在RAM中读取和写入描述符环外，您的驱动程序还需要通过其内存映射控制寄存器与E1000交互，以检测接收到数据包何时可用，并通知E1000驱动程序已经用要发送的数据包填充了一些TX描述符。然后，您需要分配一个新的mbuf并将其放入描述符中，以便当E1000再次到达RX环中的该点时，它会找到一个新的缓冲区，以便DMA新数据包。

2024-05-25 19:29:09 645 1

John_Snowww的博客