2 OS结构 - 爱码网

文章目录

2.1 操作系统服务
2.3系统调用
2.4 系统调用类型

2.4.1进程控制

OS为执行程序提供环境。从内部结构来说,操作系统变化很大,有很多组织方式。
设计一个新的操作系统是个大型任务。
在开始设计前,定义好系统目标非常重要。
所要设计系统的类型决定了如何选择各种算法和策略。

可以从多个角度来研究操作系统。
第一是通过考察所提供的服务。
第二是通过考察为用户和程序员提供的接口。
第三是研究系统的各个组成部分及其相互关系。
本章将从用户角度、程序员角度和操作系统设计人员角度来分别研究操作系统的三个方面。本章
将硏究操作系统提供什么服务、如何提供服务、设计操作系统的各种方法。最后,介绍如
何生成操作系统,以及计算机如何启动它的操作系统。

本章目标
介绍操作系统为用户、进程和其他系统提供的服务
讨论组织操作系统的不同方法。
解释如何安装、定制操作系统,及如何启动。

2.1 操作系统服务

2.3系统调用

system call提供了操作系统提供的有效服务界面。
调用常用C或C++编写,当然,对底层的任务(如必须直接访问的硬件),可能以汇编语言指令的形式提供

讨论OS如何使其系统调用可用之前,先解释如何使用系统调用:
从一个文件读数据并复制到另一个文件
输入是两个文件的名称:输入文件和输出文件名。
根据操作系统设计的不同,这些名称有许多不同的表示方法。
一种方法是程序向用户提问然后得到两个文件名。
对于交互系统
- 这种方法需要一系列的系统调用:先在屏幕上写出提示信息,再从键盘上读取定义两个文件名称的字符。
对于基于鼠标和基于图标的系统,一个文件名的菜单通常显示在一个窗口中。
- 用户通过鼠标选择源文件名,另一个类似窗口可以用来选择目的文件名。
- 这个过程需要许多I/O系统调用。

得到文件名后,该程序打开输入文件并创建输出文件。
每个操作都需要另一个系统调用。
每个操作都有可能遇到错误情况。
当程序设法打开输入文件时,它可能发现该文件不存在或者该文件受保护而不能访问。
在这些情况下,程序应该在终端上打印出消息(另一系列系统调用),并且非正常地终止(另一个系统调用)。
如果输入文件存在,那么必须创建输出文件。
用户可能会发现具有同一名称的输出文件已存在。
这种情况可能导致程序中止(一个系统调用),或者必须删除现有文件(另一个系统调用)并创建新的文件(另
个系统调用)。
对于交互式系统,另一选择是问用户(一系列的系统调用以输出提示信息并从终端读入响应)是否需要替换现有文件或中止程序。

现两个文件都已设置好,可以进入循环以从输入文件中读(一个系统调用)并向输出文件中写(另一个系统调用)。
每个读和写都必须返回一些关于各种可能错误的状态信息。
对于输入,程序可能发现已经到达文件的结東,或者在读过程中发生了一个硬件失败(如
奇偶检验误差)。
对于写,根据输出设备的不同可能出现各种错误(如没有磁盘空间打印机没纸等)。

最后,整个文件复制完成后,程序关闭两文件(另一个系统调用),在终端或窗口上写一个消息(更多系统调用),最后正常结束(最后的系统调用)。
一个简单的程序也会大量使用操作系统。
通常,系统每秒执行数千个系统调用。
图2.1：这个系统调用序列。

2 OS结构

大多数程序员不会看到这些细节。
开发人员根据API设计程序。
API是一系列适用于应用程序员的函数,包括传递给每个函数的参数及其返回的程序员想得到的值。
有三种应用程序员常用的API:适用于 Windows系统的Win32API,
适用于 POSIX系统的 POSX API(包括几乎所有UNX、 Linux和 Mac OS X版本)
用于设计运行于Java虚拟机程序的 Java API。

注意,贯穿本书的系统调用名是常用的例子,每个操作系统都有自己的系统调用命名。

2 OS结构

组成API的函数常为应用程序员调用实际的系统调用。
Win32函数Createprocess(生成一个新进程)实际上调用 Windows内核中的 NT Createprocess系统调用。
为什么应用程序员根据API来编程,而不调用系统调用?
根据API编程的好处之一
- 程序的可移植性,一个采用API设计程序的程序员希望她的程序能在任何支持同样API的系统上编译并执行(尽管事实上,体系的不同常使其很困难)。
- 此外,对一个应用程序员而言,实际的系统调用比API更注重细节和困难。
尽管如此，API中的函数和与其相关的内核系统调用之间还是常常存在紧密的联系。
事实上,许多Win32和POSX的API与UNIX、 Linux和 Windows操作系统提供的自身的系统调用是相类似的。

多数语言的运行时支持系统(与编译器一起的预先构造的函数库)提供了系统调用接口,
- 作为应用程序与操作系统的系统调用的链接。
系统调用接口截取API的函数调用,并调用操作系统中相应的系统调用。
每个系统调用一个与其相关的数字
- 系统调用接口根据这些数字维护一个列表索引。
然后,系统调用接口来调用所需的操作系统内核中的系统调用,并返回系统调用状态及其他返回值。

调用者不需知道如何执行系统调用或者执行过程中它做了什么,它只需遵循API并了解执行系统调用后,系统做了什么。
对于程序员,通过API操作系统接口的绝大多数细节被隐藏起来,并被执行支持库所管理。
API、系统调用接口和操作系统之间的关系如图2.3,
- 操作系统如何处理一个调用 opend系统调用的用户应用。

2 OS结构

系统调用根据使用的计算机的不同而不同。
通常,需要提供比所需系统调用识别符更多的信息。
这些信息的具体类型和数量根据特定操作系统和调用而有所不同。
例如,为获取输入,可能需要指定作为源的文件或设备和用于存放输入的内存区域的地址和长度。
当然,设备或文件和长度也可以隐含在调用中。

向操作系统传参有三法。
最简单通过寄存器来传递参数。
参数数量会比寄存器多。这时,这些参数通常存在内存的块和表中,并将块的地址通过寄存器来传递(见图2.4)。
- Linux和 Solaris就这方法。
参数也可通过程序放在或压入堆栈中,并通过操作系统弾出。
有的系统采用块或堆栈方法,因为这些方法并不限制所传递参数的数量或长度。

2 OS结构

2.4 系统调用类型

系统调用五类:进程控制、文件管理、设备管理、信息维护和通信。
在2.4.1到2.4.5,将简要描述操作系统可能提供的系统调用类型。
这些系统调用大多支持后面几章所讨论的有关概念和功能,或被其所支持。
图2.5总结了操作系统通常提供的系统调用类型

2 OS结构

2.4.1进程控制

运行程序需要能正常或非正常地中断其执行(end或 abort)。
如果一个系统调用被用来非正常地
- 中断执行程序,
- 或者程序运行碰到问题而引起错误陷阱,
- 那么可能会有内存信息转储并产生一个错误信息。
内存信息转储通常写到磁盘上,
- 并被调试器(帮助程序员发现和纠正错误的系统程序)检查和确定问题原因。
不管是正常还是非正常中止,操作系统都必须将控权制转交给调用命令解释器。
命令解释器接着读取下一个命令。
对于交互系统,命令解释器简单地读取下一命令,因为假定用户会采取合适的命令以处理错误。
对于GUI系统,一个弹出窗口可提醒用户出错并请求建议。
对于批处理系统,命令解释器通常终止整个作业并继续下一个作业。
当出现一个错误的时候,有的系统允许控制卡指出个具体的恢复动作。
- 控制卡是一个批处理系统概念,它是一个管理进程执行的命令。
如果程序发现输入有错并想要非正常地终止,那么它可能也需要定义一个错误级别。
- 更加严重的错误可用更高级的错误参数来表示。
如果将正常终止定义为级别为0的错误,那么可能将正常和非正常终止混合起来。
命令解释器和下一个程序能利用错误级别来自动决定下一个动作。

执行一个程序的进程或作业可能需要装入和执行另一个程序。
这一点允许命令解释器来执行一个程序,该命令可通过用户命令、鼠标单击或批处理命令来表示。
当装入程序终止时,一个有趣的问题是控制权返回到哪里。
这个问题与现有程序是否丢失、保存或与新程序继续并发执行有关。

如果新程序终止时控制权返回到现有程序,那么必须保存现有程序的内存映像。
因此,事实上创建了一个机制以便一个程序调用另一个程序。
如果两个程序并发继续,那么创建了一个新作业和进程以便多道执行。
通常,有的系统调用专门用于这一目的(如 createprocess或 submit job)。

如果创建一个新作业或进程,或一组作业或一组进程,那么应该能控制它的执行。
这种控制要求能决定和重置进程或作业的属性,包括作业的优先级、最大允许执行时间等
( get process attributes和 set process attributes)。
如果发现所创建的进程不正确或不再需要,那么也要能终止它

2 OS结构