|
进程间通信 我们提到过，当一个进程需要操作系统的帮助，它可以通过系统调用让内核来替它完成一些工作。迄今为止，我们已经熟悉了系统调用的工作机制，并且已经实现了不止一个系统调用。接下来你会发现，用户进程将会有更多事情依赖于内核。比如我们想实现一个文件系统，最起码读写硬盘的工作要求助于内核。这里我们可以逐渐地增加系统调用，但也可以采用另一种方案，就是将这些工作剥离出来，交给一些系统进程来完成，让内核只负责它必须负责的工作，比如进程调度。这种将内核工作简单化的思想，便是微内核的基本思想。而所有工作通过系统调用扔给内核态的做法，被称为宏内核。 在基于宏内核的操作系统中，完成具体任务时，用户进程通过系统调用让内核来做事，直来直去，我们之前已经很熟悉了。在基于微内核的操作系统中，这个过程稍微复杂一些。在完成具体任务时，内核的角色很像是个中介。就比如我们将要实现的文件系统吧，设想用户进程P读取一个文件，首先通过内核告诉进程FS，然后FS再通过内核告诉驱动程序(也是一个独立的进程)，驱动程序读取硬盘，返回结果。这样一来，一项工作的完成变得有些曲折，需要多个进程协同工作。于是，进程间通信也就变得至关重要了。 到如今，我们的操作系统慢慢长大，接下来我们要用它来管理磁盘和磁盘上的文件并管理内存等，这些都要向应用程序提供接口，到了必须决定用微内核还是宏内核的时候了。怎么办呢?当然不能抛个硬币了事。我们不妨先找两个具体的例子来看看它们分别是怎么回事，看完了，明白了，再做决定也不迟。 微内核还是宏内核 微内核和宏内核的例子都非常好找。我们一直拿在手边的Minix，以及每天在用的Linux，便是两者的典型例子。Minix是微内核的，Linux则是宏内核的。 说起这两个例子，有一段轶事不能不提。那就是当年Tanenbaum和Linus一老一少的口舌之争。话说Linus写了个操作系统叫做Linux，使用的是宏内核，他把这个消息发在了comp.os.minix新闻组上，这时Tanenbaum说话了，把Linux批评了一通，年轻气盛的Linus于是发信回击，这样一来二去，为我们留下一段微内核与宏内核的经典争论。 争论的全部内容在这里我们就不全部转述了，读者感兴趣的话可以用搜索引擎很容易地搜到(或者在维基百科上看一下)，我们把其中的重点说一下。在谈到微内核和宏内核时，Andy(Andrew S. Tanenbaum)是这样说的： 老一点的操作系统都是宏内核的，也就是说，整个操作系统是一个运行在核心态的单独的a.out文件，这个二进制文件包含进程管理、内存管理、文件系统以及其他。具体实例包括UNIX、MS-DOS、 VMS、MVS、OS/360、MULTICS等。 另一种便是微内核，在这种系统中操作系统的大部分都运行在单独的进程，而且多数在内核之外。它们之间通过消息传递来通信。内核的任务是处理消息传递、中断处理、底层的进程管理，以及可能的I/O。这种设计的实例有RC4000、Amoeba、Chorus、Mach，以及还没有发布的Windows/NT。 我完全可以(但不必)再讲述一段关于两者之间相对优势的很长的故事，然而在实际设计操作系统的人中间说说就够了，争论实际上已经结束。微内核已经取得了胜利。对于宏内核而言唯一的争论焦点在于效率，不过已经有足够的证据表明微内核可以像宏内核一样快(比如Rick Rashid已经发表了Mach 3.0和宏内核系统的比较报告)所以那不过是喊喊而已罢了。 Minix是微内核的，文件系统和内存管理是单独的进程，它们运行在内核之外。I/O驱动也是单独的进程(在内核之内，但仅仅是因为Intel CPU的糟糕设计使得很难不这样做)。Linux是个宏内核的系统。这相当于向七十年代倒退了一大步。就好比将一个已存在的工作得很好的C程序用Basic重写一遍。在我看来，在1991年写一个宏内核的系统真不是个好主意。” 以上前两段基本上可以被认为是宏内核和微内核的基本概念。从概念上我们不难猜到，宏内核看上去试图包办一切，而微内核恰恰相反，它的任务只是“处理消息传递、中断处理、底层的进程管理，以及可能的I/O”，而其他事情都交给内核之外单独的进程来完成。 在这段文字中Andy不但阐述了宏内核和微内核的概念，摆明了对于这个问题鲜明的观点，而且他也毫不掩饰自己对宏内核的不屑。而且这种不屑让他认为Linux简直是技术的倒退。在随后的文字中，对于Linux的可移植性Andy也做了不客气的批评。也难怪Linus对此非常恼火。从Linus的第一个回复开始，这场争论开始变得精彩起来。 |
|
|
来自： astrotycoon > 《debug》
