2021 《操作系统》实验须知

TL; DR

从 Github 下载指定的 repo，整个学期都在此目录中完成所有实验。

我们将使用我们的脚本/Makefile、在我们的环境下进行评测。因此如果你在本地修改了编译选项 (如去掉了 -Wall -Werror 等)、硬编码了路径 (fopen("/home/jyy/log.txt", "w")) 等，提交后可能会发生编译/运行错误。

因算力有限，Online Judge 仅对本校同学开放。

请大家自觉不要把自己的实验作业代码公开。如果你本着 “炫耀” 的态度公布，那你的代码很可能写得很烂不值得炫耀。公布代码会在很多层面上伤害使用你代码的学弟和学妹。

1. Academic Integrity

所有课程作业都需要独立完成。我们在此列出 Rob Miller 关于 6.031 代码独立完成的要求，作为大家理解 “独立完成” 的标准。如果你对做某件事是否合理感到困惑，可以询问老师。

Problem sets in this class are intended to be primarily individual efforts. You are encouraged to discuss approaches with other students but your code and your write-up must be your own. You may not use materials produced as course work by other students, whether in this term or previous terms, nor may you provide work for other students to use. It’s good to help other students. But as a general rule, during the time that you are helping another student, your own solution should not be visible, either to you or to them. Make a habit of closing your laptop while you’re helping. During code review, you will see classmates’ solutions to a problem set. While it is fine to take inspiration from their approach, do not copy their work. It’s fine to use material from external sources like StackOverflow, but only with proper attribution, and only if the assignment allows it. In particular, if the assignment says “implement X,” then you must create your own X, not reuse one from an external source. It’s also fine to use any code provided by this semester’s 6.031 staff (in class, readings, or problem sets), without need for attribution. Staff-provided code may not be publicly shared without permission, however, as discussed later in this document.

Example 1
- Alyssa and Ben sit next to each other with their laptops while working on a problem set. They talk in general terms about different approaches to doing the problem set. They draw diagrams on the whiteboard. When Alyssa discovers a useful class in the Java library, she mentions it to Ben. When Ben finds a StackOverflow answer that helps, he sends the URL to Alyssa. OK.
- As they type lines of code, they speak the code aloud to the other person, to make sure both people have the right code. INAPPROPRIATE.
- In a tricky part of the problem set, Alyssa and Ben look at each other’s screens and compare them so that they can get their code right. INAPPROPRIATE.
Example 2
- Jerry already finished the problem set, but his friend Ben is now struggling with a nasty bug. Jerry sits next to Ben, looks at his code, and helps him debug. OK.
- Jerry opens his own laptop, finds his solution to the problem set, and refers to it while he’s helping Ben correct his code. INAPPROPRIATE.
Example 3
- Louis had three problem sets and two quizzes this week, was away from campus for several days for a track meet, and then got sick. He’s already taken two slack days on the deadline and has made almost no progress on the problem set. Ben feels sorry for Louis and wants to help, so he sits down with Louis and talks with him about how to do the problem set while Louis is working on it. Ben already handed in his own solution, but he doesn’t open his own laptop to look at it while he’s helping Louis. OK.
- Ben opens his laptop and reads his own code while he’s helping Louis. INAPPROPRIATE.
- Ben has by now spent a couple hours with Louis, and Louis still needs help, but Ben really needs to get back to his own work. He puts his code in a Dropbox and shares it with Louis, after Louis promises only to look at it when he really has to. INAPPROPRIATE.
Example 4
- John and Ellen both worked on their problem sets separately. They exchange their test cases with each other to check their work. INAPPROPRIATE. Test cases are part of the material for the problem set, and part of the learning experience of the course. You are copying if you use somebody else’s test cases, even if temporarily.

Note that in the examples marked inappropriate above, both people are held responsible for the violation in academic honesty. Copying work, or knowingly making work available for copying, in contravention of this policy is a serious offense that may incur reduced grades, failing the course, and disciplinary action. Copying, or helping somebody copy, may result in an F on your transcript that you will not be able to drop.

2. 设置实验环境

x86-64 Linux 系统 (任意发行版)。Debian/Ubuntu 是比较新手友好的选择；推荐在物理机上安装，但也可以使用虚拟机 (请分配足够的内存和磁盘空间)。获取实验框架，在终端中执行命令

git clone https://github.com/NJU-ProjectN/os-workbench.git

将会克隆 os-workbench 到当前目录，之后的编程任务均在此完成。注意我们会在每次 make 编译的时候强制进行一次 git commit，以保存大家的代码。请大家务必使用给定的 Makefile 编译，否则可能会被判定为抄袭。希望用 git 管理代码的同学可以使用分支和 tag。

我们使用 Git 记录编程的过程 (为什么？)

如果你对 Makefile 有修改，请保留 Git 追踪部分。

如果你希望手工管理 Git 仓库，请将 master 作为你工作的主分支；你可以建立临时分支，但也请合并回 master。请妥善保管这个目录 (如果在多个地点完成作业，请将整个目录完整移动，以保持 Git 记录的完整)。如遇问题请联系老师或助教。

2.1. 实验环境

初始时，你 clone 下的目录中只有 Makefile, Makefile.lab 和 .gitignore 三个文件。在相应的实验页面上，有获取实验代码的方法。以 Mini Lab 为例，如果一切顺利，在 minilab 对应的目录中 make，将会得到 xxxx-32 和 xxxx-64 两个文件，分别是 32 位和 64 位平台上的二进制代码 (或运行库)。以下是第一个 Mini Lab (pstree) 框架代码的例子：

$ ls
Makefile  pstree.c
$ make
gcc -m64 -O1 -std=gnu11 -ggdb -Wall -Werror -Wno-unused-result ./pstree.c -o pstree-64 
gcc -m32 -O1 -std=gnu11 -ggdb -Wall -Werror -Wno-unused-result ./pstree.c -o pstree-32 
$ ls
Makefile  pstree-32*  pstree-64*  pstree.c
$ ./pstree-32 hello
argv[0] = ./pstree-32
argv[1] = hello
$ ./pstree-64 world
argv[0] = ./pstree-64
argv[1] = world
jyy@pstree/$

Trouble Shooting

一切顺利？一般都不会太顺利的。如果你第一次安装 Linux 环境，一定会遇到一些困难。给大家的建议：

(非常非常非常重要，新手经常忽略) 仔细阅读、理解输出日志，尤其是错误信息。必要的时候使用一些命令行选项打印更多的日志

在 Google/Bing/Stackoverflow 用英文关键字搜索相应的错误，并尝试解决

禁止使用中文关键字，禁止使用百度/CSDN blogs。其中的很多不准确的信息可能会误导新手

我们的阅读材料有一些入门材料，不耐心的同学可以读一下 “The Art of Command Line”，几乎有你这学期需要的全部

例如，如果你使用了非推荐的环境 (比如 Docker)，你可能会遇到 hostnamectl 没法执行的问题……你可以试着解决这个问题，但我们不推荐使用 docker——在未来你会遇到更多的问题。Docker 并不是设计给开发用的，而是给部署用的。

再比如在64位环境下，如果没有安装编译器和相应的运行库，则第一次编译就会失败；如果安装了，-m32 也会编译错误，例如：

In file included from /usr/include/features.h:399:0,
                 from /usr/include/stdio.h:27,
                 from ./pstree.c:1:
/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
 # include <gnu/stubs-32.h>
                           ^
compilation terminated.
make: *** [pstree-32] Error 1

这时候，两个反复提到的词再次出现：

RTFM: Read The Friendly Manual
STFW: Search The Friendly Web

其中的 “F” 让它们更具有传奇色彩。通过查阅官方文档和搜索互联网解决你遇到的问题，在《计算机系统基础》这门课中已经得到了充分的训练。再次强调要看清楚网上的解决方案是否适合你的系统环境，以及是否说明了出问题的原因。make 编译成功后，将会得到 pstree-32 和 pstree-64 两个文件，在命令行中执行可以打印所有命令行参数。

-32, -64?

同一份代码，Makefile 会同时使用 -m32 和 -m64 两个选项来编译。这帮 (强) 助 (制) 大家写出可移植的代码。CERT C 编码规范是非常棒的阅读材料，也作为书籍出版，大家可以收藏一本电子版。

2.2. 注意事项

Mini Labs 注意事项

在 Linux 下完成。你的代码同时兼容 32/64 位环境是强制必须实现的，并在测试用例中体现。

全程只有一个 C 源代码文件，请尽量控制在 500 行以内。参考实现一般在 100-200 行，测试通过即得满分。Mini Programming Labs 的扩展性极高，顺着写下去，1,000 行，10,000 行，100,000 行都是有可能的，请克制你的欲望。

只允许使用指定的 Makefile 编译 (使用 make)、只允许编辑已有的一个 .c文件。评测时，我们仅复制这一个 C 文件 (添加其他文件在 Online Judge 会导致编译错误)。

不需要实验报告。

OS Labs 注意事项

同样需要编写可移植的代码。我们将在 native, x86_64-qemu, x86-qemu 三个平台上测试。

需要撰写实验报告 (以 pdf 格式存储在实验目录中)。除非特殊情况，实验报告不建议超过 2 页 A4 纸。请在实验报告中描述你在实验中遇到的特别值得一提的事件，例如你代码的架构设计、特别精巧的实现、遇到印象深刻的 bug 等。无需事无巨细交代清楚；好的代码不言自明。

3. 实验提交

我们将为会每个选修课程的同学生成一个唯一的秘钥 (以邮件形式发送到你的学号@smail.nju.edu.cn 邮箱，请保存好这一封邮件)。你需要配置好 TOKEN 环境变量为你收到的秘钥，你可以在 shell 中执行 (或写 bashrc 或 Makefile 中，就像我们的 Makefile 一样，从而不用每次输入)

export TOKEN=xxxxxxxx

作为实验的热身，你需要在互联网上搜索什么是环境变量 (尽管现在你可能理解得并非完全彻底，但随着课程进展，我们会详细地讲解这部分)。配置好环境变量后，在相应的实验目录中执行 make submit 自动完成提交，如果提交成功，命令行中会看到：

$ make submit
[SUCC ✓] Received OS2021-M1 学号 (姓名) upload.tar.bz2 at 20:17:26

提交成功后，将你收到的秘钥粘贴到网页的右上角，在实验网页上查看提交结果。

4. 评测与评分

4.1. 文件收取与提交

OJ只收取 os-workbench/.git 文件。因此提交时确保你的改动进入了 Git Repo (例如，通过 make 或手工提交)。请注意——如果你在子目录中创建了 nested git repo，可能导致你的提交没有被 os-workbench/.git 记录。

4.2. 在线评测 Online Judge

Online Judge 基于计算机系云平台。程序在容器中编译、运行，并由机器自动判定结果是否正确。在此基础上，最终实验的评分仍有一部分由助教决定。你的程序将在以下环境运行：

虚拟机中的 Ubuntu 20.04 容器 (Docker)。容器中仅有最小的必要系统工具。使用以下 Dockerfile 配置与在线评测一致的环境；我们开放了容器的 SYS_PTRACE 权限；

FROM ubuntu:20.04
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update
RUN apt-get install -y build-essential gcc-multilib qemu-system strace gdb sudo python3 libsdl2-dev libreadline-dev && apt-get upgrade -y
RUN useradd -ms /bin/bash oj
USER oj
WORKDIR /home/oj

Mini Labs 直接在容器中执行 (non-root user)；OS Labs 在容器中的 QEMU 虚拟机 (tcg 模式) 运行；
容器总内存限制 512 MiB，超过内存限会导致进程被杀死。超过一定时限未执行完的容器也将被杀死。

被 Online Judge 支配的恐惧？

Online Judge 的最大特点就是严格。有任何差错 (因为环境/配置等引发的编译错、细小的输出错误) 都将被 Online Judge 捕捉到。这有助于帮助大家摆脱 “糊弄” 的习惯，编写正确的程序。

系统课程的 labs 和 OJ 题有一点不同：大部分问题没有 “绝对正确” 的标准输出。因此我们并不是简单地运行程序检查结果，而是有一定系统化地测试你的程序：

在多个环境下运行你的程序，如 i386 (32 位) 和 x86-64 (64位)，因此不可移植的代码可能无法编译；

在模拟出的环境中执行程序，例如在线程调度时插入一些随机的 delays，从而提高某些并发 bug 触发的概率；

链接我们修改过的库函数，例如 (在某些 lab 中) 使 malloc() 随机返回 NULL；

解析程序的 log，并观察其中是否有 bug 出现的迹象。例如程序 crash 将被判定为不正确、缺少某个重要输出也将被判定为不正确。

4.3. 评分方法

测试用例分为两个等级 (easy 和 hard)，easy 通常是一些 “冒烟测试” (smoke test)，即使用最典型简单的方式运行程序，检查程序是否 crash 以及输出合理的结果。Hard 则是更接近实际应用场景的测试用例。虽然你不能看到程序的日志输出 (否则测试用例很容易泄露)，但我们会对每个测试用例提供一定的解释，以帮助大家诊断问题。与此同时，我们也会保留一定数量的测试用例用于评分使用，最终的评分将结合自动评测、保留测试用例和人工评价给出。评分规则：

评分规则

在没有抄袭和作弊 (如硬编码答案、故意骗过 Online Judge 而不实现实验要求等) 的前提下

Mini Labs (完全客观评分)

Rejected, 编译错误或没有通过任何测试用例: 10% (诚信分)

Accepted, 部分 easy 测试通过 (此时不运行 hard 用例): 50%

Accepted, 全部 easy 测试通过、部分 hard 测试通过: 75%

Accepted, 通过全部 easy/hard 测试: 100%

OS Labs (几乎完全客观评分)

Rejected, 编译错误或没有通过任何测试用例: 10% (诚信分)

Accepted, 部分 easy 测试通过 (此时不运行 hard 用例): 30%

Accepted, 全部 easy 测试通过、部分 hard 测试通过: ≥ 50%，剩余部分由隐藏的测试用例/人工评价给出

Accepted, 通过全部 easy/hard 测试: ≥ 75%，剩余部分由隐藏的测试用例/人工评价给出

没有通过全部 easy 测试用例的作业将没有人工评分的机会 (即意味着实验报告不得分。但我们会阅读你的反馈)。

我们希望这个机制能够强制大家写出高质量的代码。一开始会很痛苦，但之后你方能体会其中的良苦用心。

按时提交奖励

每个实验都设有 Soft deadline。Soft deadline 之前提交：成绩 + 5% (如按时提交空项目将得到 15% 诚信分)

单项得分可以超过 100% (例如按时提交正确的 Mini Lab 将得到该 lab 的 105%)

Mini/OS Labs 得分由所有单个 Mini/OS Lab 得分总和而成，不超过 Mini/OS Labs 总分的 100%

如果发现问题希望修复 (一旦进行过尝试)，之后的提交将不享受加分；但之前已经获得带按时提交加分的分数不会被消除 (以分数高的计算)

所有实验在 Hard deadline (通常是期末考试后的一小段时间) 截止。请《计算机系统基础》课上将实验拖延到最后的同学吸取教训。

温 (血) 馨 (的) 提 (教) 示 (训)

Online Judge 平台并行度有限，遇到评测任务较多时请耐心等待，请避免在截止日期前极限操作，否则你将来不及修复 Online Judge 返回的错误。