莱昂氏UNIX源代码分析二十七.pdfVIP

下载 第26章 练 习 任何一个操作系统的设计都与设计者的很多主观判断及解决实际问题的方法有关。在 U N I X源代码的很多部分，你作为读者很可能提出这样的问题：“为什么U N I X 的设计者以这种 方法设计、编写这段程序呢 ? ”，“如果我对此作了更改，那么其后果又会是什么呢? ” 下面的练习就提出了一些这样的问题。其中有些问题可以在更深入地研究、分析了有关 源代码部分后得到答案，有些问题则需进行某种实验性的试探和测试，在作这种试探时，通 过终端对/ d e v / k m e m进行只读存取是极其有益的；而另一些则要求构造和测试 U N I X操作系统 的实验性版本。 第一部分 1.1 请更改“m a l l o c ”( 2 5 2 8 )，使其实现最佳适配(Best Fit)算法。 1.2 改写过程“m f r e e ”( 2 5 5 6 ) ，使其功能对读者更加清晰，易于分析。 1.3 查验数组“c o r e m a p ”和“s w a p m a p ”( 0 2 0 3 、0 2 0 4 ) 的长度是否适当。当增加“N P R O ” 时，如何相应地对“C M A P S I Z ”和“S M A P S I Z ”作更改? 1.4 证明“m a l l o c ”和“m f r e e ”合作正确地解决了存储器分配问题。 1.5 监测“c o r e m a p ”内容的变化情况，然后分析评估内存的使用效率。同时也评估经常 压紧内存正在使用的区间以减少内存碎片所造成的开销，从而回答下面的问题：将目前使用 的内存分配方法扩展成包括内存压缩是否值得 ? 1.6 在设置前6个核心页的说明寄存器时， U N I X 并没有使用硬件保护的所有可用特征，例 如只包含纯正文的页可被设置为只读。请修改源代码，尽可能使用可用的硬件保护功能。 1.7 编译下列程序 char *init″/ e t c / i n i t″ main( ) { e x e c l ( i n i t , i n i t , 0 ) ; w h i l e ( 1 ) ; } 并将编译所得结果与数组“ i c o d e ”( 1 5 1 6 ) 的内容相比较。 1.8 请查验核心态栈区所需的长度，从而说明现在提供的该区长度 3 6 7字是适当的。 1.9 如果主存由若干独立的存储模块组成，而其中之一 (不是最后一个模块 )不再工作，那 么“m a i n ”将不包括该模块及其后的各模块至“ c o r e m a p ”的可用空间中。请对“m a i n ”作简 单修改以处理这种情况。系统中的哪些部分也需要修改呢 ? 1.10 重写例程“e s t a b u r ”( 1 6 5 0 )和“s u r e g ”( 1 7 3 9 )，使它们在P D P 1 1上尽可能高效地工作。 364 下篇 莱昂氏UNIX源代码分析 下载 实际上使用这些例程的频繁程度会多高呢 ?是否值得实现经你改进了的版本呢 ? 1 . 11 分析启动一个新进程的开销。在不同的条件下，对一组不同长度的程序进行一系列 测试。 1.12 评估下述进程调度方案，肯·汤姆森曾试图以此为基础提出一个修订过的调度算 法： 每个进程都有一个数“ p ”，并将其存放在“p _ c p u ”中。进程在执行时，每个时钟滴答其 “p ”值加1。因此“p ”累计了该进程对C P U 的使用时间。每一秒钟，每个进程的“ p ”都取其 原先值的五分之四，并取为最近的一个整数。所以，“p ”的边界值是 0和方程｛Ｋ＝ 0 . 8 × （k + H z ) } 的解，亦即４×Ｈz 。因此，若H z 是5 0或6 0 ，而且“p ”取整，那么“p ”可存放在一 个字节中。 1.13 对“p r o c ”表用线性法进行搜索。随着该表长度的增加，相应的搜索开销也增加。 请提出一种方法改进此搜索机构 (例如当N P R O C 为3 0 0时) 。 第二部分 2.1 详细解释处理机在核心态运行时若发生浮点陷入，系统对此的反应是什么 ? 2.