操作系统(jyyOS)_M系列实验感想
M1-pstree
- 思维难度:⭐
- 代码难度:⭐⭐
- 消耗时长:⭐⭐⭐
唯一的挑战在于配好WSL和上手Linux系统编程,除此之外没有任何难度。一开始jyy的submit脚本写bug了,只收集了git commit
的部分,导致我一直在交空仓库上去;不得不顶着提交次数限制面向 OJ 编程将近一个小时,终于查出来了自己交的是空仓库。
M2-libco
- 思维难度:⭐⭐⭐⭐
- 代码难度:⭐⭐⭐⭐
- 消耗时长:⭐⭐⭐⭐⭐
给我带来了一点小小的系统编程震撼。wrapper
和stack_switch_call
的机制都非常巧妙,痛苦debug的感想发布在了知乎上(https://www.zhihu.com/question/34787444/answer/3458466485),这里就不重复写了。
认识到了即便是C语言也是有局限性的,抛开一切高级语言的约定,确实可以用汇编整出很花的活。
M3-gpt.c
- 思维难度:⭐
- 代码难度:⭐
- 消耗时长:⭐
整个学期最快乐的一次OJ,借用群里同学的话说:「配sperf的时间比写代码的时间长」。其实还是有一些小trick,导致我一开始在TLE:给多线程分配任务的时候,不要切的太碎;如果有 $4$ 个CPU能用,就直接把任务切成 $4$ 份;一开始我把任务切成了 $n$ 份($n\geq 20$),导致出现了严重的调度性能问题,且由于我本机是 $20$ 核的,导致我根本没有感受到调度压力。
M4-crepl
- 思维难度:⭐⭐
- 代码难度:⭐⭐
- 消耗时长:⭐⭐⭐
基本也属于放松自我的OJ。一开始我在思考:如果子进程死了,那么父进程怎么知道它死了?在这里内耗了不少时间,做了个实验发现有BROKEN_PIPE
这个机制,就好解决了。
出于仿照jyy的聊天室的想法,我把这个东西打包到了我的服务器上,使用 ssh crepl@iamdanny.online
即可连接使用。 实现方法非常暴力:创建了一个 crepl
用户,把 shell
注册成 crepl
程序;后来发现jyy不是这么干的,在openssh server层面强制执行确实是更好的办法(支持所有用户名、更加安全)。
M5-sperf
- 思维难度:⭐⭐
- 代码难度:⭐⭐
- 消耗时长:⭐⭐
主要的难点在于:如何把strace
的输出和被追踪程序分离开。我使用了一些神秘的方法:在/tmp
下创建了一个临时的命名FIFO管道,指定sperf
输出到这个文件里面去。
M6-fsrecov
- 思维难度:⭐⭐(仅恢复文件名)
- 代码难度:⭐⭐(仅恢复文件名)
- 消耗时长:⭐⭐⭐(仅恢复文件名)
- 思维难度:⭐⭐⭐(恢复图片)
- 代码难度:⭐⭐⭐(恢复图片)
- 消耗时长:我没做(恢复图片)
如果只做恢复文件名的话,把手册看一遍其实不难;尤其是:jyy给出了一个readfat
的示例程序;且 FAT32 足够简单以至于我可以开着hexedit
跟手册对。图片的恢复我想到了以下的idea,但是没写:我们已知一个图片的一个片段大概率是在内存中连续存储的;因此我们扫过整个镜像,将镜像分为一段段的“疑似连续段”,然后将这些“疑似连续段”进行暴力拼接即可。
总结
总的说来,M系列的设计目的就是:让大家熟悉系统编程,特别地,利用Linux系统机制和系统调用,编写出有鲁棒性和一致性的程序。M实验上手以后就很轻松,除了M2都可以一晚上速通,然后把时间留给L系列折磨。
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 IAD's Blog!