MINIX3 导读分析

一个操作系统的分析是属于一个非常庞大的工程,操作系统就像是一个人造的
人,每一个模块想完全发挥功效,很有可能需要很多模块的支持才能够实现。所
以在分析 MINIX3 时,我认为同时看多个模块对于理解 MINIX3 是有好处的,特
别是因为 MINIX3 是采用微内核结构,也就造成阅读源码的一个比较大的障碍。
在此我统领的描述下 MINIX3 和 PM 部分内容,给读者 MINIX3 形成一个整体的
导读框架:

1 MINIX3 采用微内核结构,什么是微内核呢?MINIX3 设计者认为除了部分非
常重要的 像中断机制,消息机制,保护模式机制等实现,必须处在内核里执行,
其他模块都放在放在用户模块执行。这种设计思想可能和 LINUX/UNIX 有非常
大的不同,以 LINUX 为例,LIUNX 将驱动,进程管理,内存管理,中断,消息
机制等等都放在内核中,这就造成了 LINUX 内核非常的庞大,MINIX3 设计者
认为,内核越大,不安全的可能性就越大,这点我没有把握,但是有点我是相信
的,内核越大,维护越大,随着内核不断的扩大,给内核维护者带来极大的困难。
MINIX3 怎么实现这种微内核机制呢?MINIX3 采用非常巧妙的方法:------消息
传递机制。利用消息传递机制来实现内核和外核的通信,当然不光光是消息传递
机制,也要通过非常复杂的布局才能够实现,关于消息传递机制,可以参考进程
间通信模块分析那一章。

2    MINIX3 怎么实现中断机制呢?MINIX3 为了兼容 8259,设立了非常多的编

程技巧来完成整个中断机制,对于中断陷入,中断执行,以及中断的收尾工作,
都体现了 MINIX3 优秀的设计思想-------简明,技巧. 具体内核可以参考 MINIX3

中断处理分析

3  MINIX3 在 386 平台能够得以运行,就必须容忍 386 这个历史包袱。MINIX3 很巧妙的省去了一些繁杂的工作。以很简单的模式驾驭了  386,具体可以参考 MINIX3 保护模式分析

4   时钟是可谓是整个 MINIX3 一个最核心的部件,事实上时钟是所有分时操作

系统的运行的心脏,MINIX3 是如何使得时钟能够得以高效安全的运行呢?怎么
来处理多个内核警报器问题呢? 具体内容可以参考 MINIX3 内核时钟分析那一

5    进程调度的好坏可以说是对整个系统的响应起着最重要的作用。MINIX3 将 进程调度编写的简单小巧,调度算法耗时非常少,但是却能够得以高效的进行, MINIX3 是怎么做到的呢

具体的内容可以参考 MINIX3 进程调度分析那一章

6  用户使用一个操作系统主要希望操作系统能够帮忙完成一个任务,举一个非 常简单的例子,如果我希望操作系统告诉我现在是多长时间,或者我想请操作系 统内核帮我申请一块内存,这些都涉及到系统调用,事实上,MINIX3 的系统调 用和 LINUX 的系统调用是不同的,主要也是由于微内核的原因,到底差异在哪 里,怎么理解这个差异性,MINIX3  又是怎么实现系统调用的?具体内容参考 MINIX3 系统调用分析那一章

7  用户希望操作系统提供信号量机制来实现用户进程间的异步,MINIX3  通过

PM 和内核共同来巧妙的实现了 MINIX3 的信号量机制,这里主要参考 MINIX3 信号量机制

8  用户的 alarm 调用是由谁来处理呢?是由前面的 MINIX3 内核时钟吗?可能

你已经注意到,时钟前加了内核,那么应该也有外核时钟!对,你猜的没有错, 的确有外核时钟这个说法,但是硬件时钟只有一个,MINIX3 是通过什么样的机
制来实现内核和外核时钟呢?具体内容参考 MINIX3PM 时钟分析和 MINIX3 内
核时钟分析。

9  通过上面 1 到 8,你们可能觉得整个 MINIX3 被我拆散的不像样子了,我们是 不是应该把 MINIX3 整合一下,用定量的 或者定性的技巧分析下 MINIX3 的性 能,当然这个分析仅仅是个尝试,做出一个精准的分析,已经完全超出我的能力 范围。我仅仅是提供一个我的思路。具体内容参考 MINIX3 整体性能分析

时间: 2024-11-02 20:29:32

MINIX3 导读分析的相关文章

MINIX3 进程调度分析

5.1MINIX3 进程调度概要 MINIX3 的进程调度还是非常简单的,调度算法是非常短小的,其目的就是体现 了一个简单和高效的设计原则,当然简单和高效其实很难并存,整体而言,就是 一个多队列调度算法,根据优先级来放到相应的位置. 我们现在来看下整个图示:(下面这个图其实就是 MINIX3 初始化时用户还没有 创建进程时所显示的图),在层次一,被认为是系统层,级别最高,是包括 system 和 clock 任务,之后第 2 层就是 tty(终端进程,在 I/O 中用到的一个进程,本分 析文档暂

MINIX3 进程通信分析

6.1MINIX3 进程通信概要 MINIX3 的进程通信是 MINIX3 内核部分最重要的一个部件,我个人认为其实这 是内核中的"内核",怎么来理解这个概念呢?其实 MINIX3 进程间通信部件的 实行不完全依赖任何一个部件,这个在后面会详细的看到.Minix3  实现进程通 信的方法是----消息机制.何为消息机制呢? 就是进程 A 有消息发送进程 B,希望进程 B 给进程 A 一个服务,进程 A 和 B 在 这里就发生了进程间的通信 注意这里的消息机制其实是不受任何机制管制,具有

MINIX3 内核时钟分析

4.1 内核时钟概要 先想想为什么 OS 需要时钟?时钟是异步的一个非常重要的标志,设想一下,如 果我们的应用程序需要在多少秒后将触发某个程序或者进程,我们该怎么做到? 就需要一个时钟的鼎力相助才能完成这个项工作.我的意思非常明确,就是说内 核时钟就是一个非常重要的部件,它可以完成分时系统的调度功能,同时它也能 为应用程序提供一个非常方便的异步处理问题的功能 现在我们简要的来看下时钟芯片的构造基本原理,如果需要了解详细的时钟芯 片,可以参考 intel 时钟芯片的详细编程资料. 一般时钟芯片就是

MINIX3 内核整体架构回顾及内核定 性分析

MINIX3  内核整体架构回顾及内核定 性分析 12.1 注意事项 由于本文档不对 I/O 文件系统做出分析,所以在此不对 MINIX3 整体做出一个分 析,本章主要是针对内核进程分析.并且这里的模型建立是非常理想化的. 12.2 MINIX3 架构 MINIX3 的设计理念就是设计一个比当前主流的系统更加稳定和可靠系统.从而 MINIX3 也就是提出一个非常经典的模式:就是系统服务器进程的概念.这些系 统服务器进程是外核的一部分,但是可以和内核通信.最为重要的设计理念是这 些服务器进程既然作

对Minix3中进程模型的简要分析

简单介绍 Minix(Mini UNIX)原来是荷兰阿姆斯特丹的Vrije大学计算机科学系的Andrew S. Tanenbaum教授所发展的一个类Unix操作系统. 目前的Minix版本为Minix 3,是一个免费.开源的操作系统,设计目标是实现高可靠性.灵活性及安全性. 其系统主要包括在核心模式下运作的微核心和在用户模式下作为一系列独立.受保护的进程运行的其余所有操作系统组件. Minix3的整体认识 MINIX3本身就是一组进程的集合 第一层的主要功能是为上层驱动程序和服务器提供一组特权内

导读-软件分析基本思路

我们准备去解决一个问题的时候,总会从分析开始,再通过分析的结果,根据我们的知识结构,给出我们认为最佳的解决方案. 道生一.一生二.二生三.三生万物. 道,是一个抽象的存在,也就是规律的意思.按照这个规律产生一个现实的物体,一个物体由阴阳两面构成,阴阳又各有阴阳,按此分解,便形成了万物.而反过来,一万个物体,我们总能够抽象出一个共同的规律,这个规律就是我们所说的道. 以上描述的规律,实际上就是一棵无限二叉树.我们的世界就是这么一个多维二叉树的形式存在,我们并不知道起点在哪里,但是当我们假设某个点为

MINIX3 系统任务分析

7.1 MINIX3 系统任务概要 MINIX3 怎么来给用户提供丰富的服务呢?除了中断,异常处理,除了时钟服务. 程序员总是希望一个操作系统给他提供足够的服务,使得他能够做出更加高效安 全的程序来.在 MINIX3 中,它提供了一种系统任务机制.这个机制的作用就是 介绍任何想调用系统调用的函数消息,之后将其进行一个精准的处理,使得其能 够对程序员提供帮助. MINIX3 整体架构设计成 C/ S 模型,以 PM 为例,PM 其实在 MINIX3 看来就是 就是一个服务进程,用户就是客户端,用户

Batch Normalization导读

/* 版权声明:可以任意转载,转载时请标明文章原始出处和作者信息 .*/ author: 张俊林 Batch Normalization作为最近一年来DL的重要成果,已经广泛被证明其有效性和重要性.目前几乎已经成为DL的标配了,任何有志于学习DL的同学们朋友们雷迪斯俺的詹特曼们都应该好好学一学BN.BN倒过来看就是NB,因为这个技术确实很NB,虽然有些细节处理还解释不清其理论原因,但是实践证明好用才是真的好,别忘了DL从Hinton对深层网络做Pre-Train开始就是一个经验领先于理论分析的偏

【Cloud Foundry】Could Foundry学习(二)——核心组件分析

在阅读的过程中有不论什么问题,欢迎一起交流 邮箱:[email protected]    QQ:1494713801 Cloud Foundry核心组件架构图例如以下: 主要组件:     Cloud Controller:实质上是VMC和STS交互的server端,它收到指令后发消息到各模快,管理整个云的执行.相当于Cloud Foundry的大脑. DEA:负责处理对所部署的App的訪问请求.事实上质是打包和訪问Droplet.当中Droplet是通过Stager组件将提交的源码及Clou