课程学习总结报告

Posted 2020-12-16 hambug

一.linux系统概念模型：

其实这个模型老师在课堂上已经给出了，张贴在下面作为参考：

 

 

 操作系统概念：

在介绍这个系统模型之前，我觉得应该先弄清楚操作系统是什么，给出操作系统的概念：

操作系统(Operating System，简称OS)是管理计算机硬件与软件资源的计算机程序。

 

模型基本构造解释：

简而言之，操作系统是用来管理计算机资源的，这部分的资源又分硬件和软件。首先对于程序员而言，最直观的能接受到的资源实际上是软件资源，在linux系统中，所有硬件资源都可以以文件的方式存在，抽象成了程序员可控一类软件资源。但既然是用来对资源进行管理的，那除了提供给用户的操作接口，还应该有对资源的各种调度和统筹规划，这一部分的内容不应该对用户进行开放，因为用户的操作可能使其原有的逻辑基础崩塌，导致操作系统的崩溃。那为了，操作系统对资源控制的稳定性和高效性，自然要将其核心工作和用户分开，单独成为一个核心状态，然后再提供接口，使得用户可以调用它管理的资源。这样linux系统的结构就很清晰了。就应该如同图中模型那样，从里到外依次为：

核心态-》系统调用-》API和SHELL（提供给用户的接口）-》用户

 

模型运转流程分析：

好了，既然分析完Linux系统的架构，那么前文也说过了，操作系统的功能是用来管理资源的，那么用户获取计算机的某一项资源的大致流程在操作系统中又是如何实现的呢？即上述模型是如何运转的呢？

1.首先用户或通过shell，直观的调取资源（例如打开某个文件），或通过编写代码，使用API获取某项资源

 

2.然后shell和API则会调用它们封装的系统调用

 

3.系统调用以某种方式是用户态陷入内核态，当然具体分析我们知道，这种方式就是trap，再细分一点就是中断描述符表项的一类系统门，所谓用户态陷入内核态也就是上下文的切换，进程运行环境的改变

这时，用户虽然和操作系统的核心有界限，但其程序的运行环境已经得以切换进内核态，即可以调度想要获取的资源。

 

4.进入内核态后，会通过一系列的手段来判断用户的操作是否合法，就像上文所述，本来讲用户态和内核态进行划分，就是为了使得用户不得干扰操作系统的核心工作，如果用户的操作没有限制，这样的划分就没有意义，所有加在用户获取资源的种种限制就反映成了对用户操作的各种检查，对其合法性的各种规定上。

如果一个操作是合法的，那么在核心态，操作系统就能通过一系列的算法来兼顾速度，安全，可靠这些方面来调度出操作所需要获取的资源，再将其通过相反路径返回给用户。

资源成功返回给用户后，用户对资源的获取就算完成了，整个资源管理的流程也大致完成了，即使用操作系统的目的达到了。

 

5.模型的运转结束。

 

二.实际例程的分析：
因为上面讲得模型大多都停留在软件层面，下面选用一个调用I/O驱动的例子来具体验证模型

举一个简单的程序员点亮LED灯的实际案例。

驱动程序介绍：

首先我们知道如果没有操作系统，点亮一个LED灯需要对CPU的I/O输出管脚十分了解，一般为了节省CPU计算资源和输出CPU电平控制，又会在CPU上再连接其它的控制芯片来对接实际的LED灯，那如果要点亮LED，就要对硬件层面的操作十分熟悉，而如今的计算机功能十分强大，能控制的资源很多，对每一个设备硬件管脚了如指掌显然不切实际。

为了解决这个问题，就可以由硬件的生产厂家编写驱动程序，也就是封装好的管脚使能程序，并提供接口给用户使用。驱动程序呢又被封装成一个文件，以文件的形式挂载在文件系统上。

现在我们回归到一开始的问题：程序员通过操作系统点亮LED灯

 

1.之前说过LED的驱动程序会被封装成文件形式，所以程序员应该做的第一件事，是打开一个设备文件

2.打开设备文件就是调用OPEN函数，OPEN函数就是模型中的API，OPEN函数又会调用系统调用sys_open()

3.这里已经开始使用模型中的系统调用了，

系统调用会被操作系统识别-> 在中断描述表中，找到对应的表项，通过表项里面的内容，判断操作是否合法，-> 操作合法，再从表项中，获取中断或异常处理程序地址，找到程序地址后进入程序。->一般进入中断处理程序的第一件事就是保存现场，以方便后面再从核心态回到用户态，继续执行用户态的程序。->接着就执行系统调用的具体程序，即创建一个表项（系统打开文件表），识别出来这个表项是设备文件，->再去获取设备描述符，通过设备描述符，来找到相应的去驱动程序，将这个驱动程序的地址写进系统打开文件表中，->系统打开文件表再被装填进FD数组，即文件描述符数组，然后返回fd，一个整数，

返回过程就是上述过程的逆过程，细节上肯定有很大的不同。但是是如同模型所示，从核心态又返回到了用户态。

4.此时调取LED硬件资源的功能已经完成（得到了fd，即设备文件的地址），但是我们还没对其进行操作，我们要点亮它，一般是通过另一个系统调用_sys_write()，通过fd找到设备文件，再调取驱动程序对设备文件进行操作，真正的点亮LED灯。

所以完整的一个流程要经过多次系统调用，才能使用户态操作底层硬件设备。也印证了模型的自洽性。