CN109918054B - 一种基于形式化规范的服务总线微内核框架设计方法 - Google Patents

Abstract

本发明公开了一种基于形式化规范的服务总线微内核框架设计方法，首先对自然语言规范进行形式化描述，并利用霍尔逻辑抽象进程间通信原语的形式化规范；然后基于形式化描述开发设计框架；在该微内核框架中定义事件服务总线，事件服务总线直接接收通过进程间通信原语陷入内核的事件，并根据获取的数据决定是切换到网络服务代理还是本地服务处理；事件服务总线根据服务号查找对应系统服务，并调用系统服务完成相应功能；系统服务直接与硬件交互，并返回结果；普通硬件设备产生的硬件中断由事件服务总线处理，智能硬件设备由自带的控制器处理中断，并调用中断服务子例程完成服务。该框架以事件驱动服务总线为中心完成微内核的设计。

Description

一种基于形式化规范的服务总线微内核框架设计方法

技术领域

本发明涉及操作系统微内核技术领域，尤其涉及一种基于形式化规范的服务总线微内核框架设计方法。

背景技术

操作系统的体系框架设计对于一个计算机系统的性能起着至关重要的作用，而对于操作系统的体系框架设计这个开放的问题，目前主要形成两大种类的体系框架设计：宏内核框架设计与微内核框架设计。

宏内核框架设计的操作系统将操作系统的主要各个系统功能作为一个紧密联系的整体来运行在系统的内核态下，此框架设计利用系统各功能之间共享信息的特点来有效利用各功能特性以提高系统整体性能。而随着操作系统功能的增加与接口形式的复杂化，宏内核框架的系统代码越来越难维护，于是便又提出了微内核的设计框架。微内核框架设计的操作系统将系统的基本功能留在系统的内核里，而将操作系统的各个系统功能模块化并移出内核运行，从而降低了内核的设计复杂性。模块化的系统服务之间相互独立，并通过微内核来相互通信。微内核框架设计有效得分离了内核与系统服务，以及系统服务与系统服务，使接口更加规范清晰，降低了内核代码的维护代价，提高了系统的可靠性。

在设计与开发微内核框架时还需考虑内核以及系统的安全性等多方面问题，目前常见的设计规范文档都是由自然语言描述的，而自然语言描述的规范会产生不可避免的二义性，这在实现过程中可能会误导开发人员，从而影响系统的安全性与正确性。

本发明在开发前对设计的自然语言规范做出形式化的描述，并利用霍尔逻辑抽象通信原语的规范，根据形式化描述来开发可提高系统的安全性与正确性。霍尔逻辑是一组使用严格数理逻辑推理计算机程序正确性的逻辑规则组成的形式系统，中心特征是霍尔三元组，形式为：{P}C{Q}，这里的P和Q是断言，C是命令，P称为前条件，Q称为后条件，这种三元组用于描述一段代码的执行如何改变计算的状态。

发明内容

本发明提出了一种基于形式化规范的服务总线微内核框架设计方法，包括：

步骤一：对基于服务总线的微内核框架设计的自然语言规范进行形式化描述，并利用霍尔逻辑抽象进程间通信(IPC，Inter-Process Communication)原语的形式化规范；

步骤二：基于形式化描述开发设计框架，首先在微内核框架中定义事件服务总线(ESB，Event Service Bus)，事件服务总线直接接收通过进程间通信原语陷入内核的事件，并根据获取的数据决定切换到网络服务代理(ESP，Event Server Proxy)或本地服务处理；

步骤三：事件服务总线根据获取的服务号查找对应系统服务，并调用系统服务完成相应功能；

步骤四：系统服务直接与硬件交互，并返回结果；

步骤五：若为普通硬件设备产生的硬件中断，由事件服务总线处理硬件中断，事件服务总线调用系统服务完成中断处理，并将处理结果返回给应用程序；若为智能硬件设备产生的硬件中断，则由设备自带的控制器处理中断，然后直接调用相关中断服务子例程完成服务，并将处理结果返回给应用程序。

本发明提出的基于形式化规范的服务总线微内核框架设计方法中，所述步骤步骤二中，在微内核框架中定义事件服务总线包括以下步骤：

步骤A1：在微内核中添加事件服务总线的数据结构；

步骤A2：在微内核初始化后直接开启所述事件服务总线。

本发明提出的基于形式化规范的服务总线微内核框架设计方法中，所述步骤二事件服务总线直接接收通过进程间通信原语陷入内核的事件包括以下步骤：

步骤B1：用户态的应用程序调用进程间通信原语接口陷入内核，并通过编码通信帧传递数据；

步骤B2：内核态的事件服务总线直接接收到通信帧，且系统权限由用户态直接切换到内核态。

本发明提出的基于形式化规范的服务总线微内核框架设计方法中，所述步骤B1中编码通信帧包括以下步骤：

步骤C1:若用户态的应用程序为内部本地应用，则在编码事件服务总线通信帧时传递应用程序的端口信息，调用的通信原语类型，调用的系统服务号，通信帧的长度，以及所需传入的数据信息；

步骤C2：若用户态的应用程序为外部网络应用，则在编码事件服务总线通信帧时传递应用程序调用的通信原语类型、调用的系统服务号、通信帧的长度和传递网络通信中的相关信息，所述相关信息包括：发送与确认序列号、网络协议类型、路由跳数、字节序、质量和多级的源端与目的端的网络地址，以及所需传入的数据信息。

本发明提出的基于形式化规范的服务总线微内核框架设计方法中，所述步骤二中根据获取的数据决定切换到网络服务代理或本地服务处理总线包括以下步骤：

步骤D1：解码通信帧得到数据信息，并根据通信帧的长度信息判断应用程序类型；

步骤D2：若应用程序为外部的网络应用则事件服务总线切换到对应的网络服务代理；

步骤D3：若应用程序为内部的本地应用，则直接进行本地服务处理。

本发明提出的基于形式化规范的服务总线微内核框架设计方法中，所述步骤三中查找，调用并完成相应系统服务功能包括以下步骤：

步骤E1：根据解码通信帧得到的服务号在服务向量表中查找对应的系统服务；

步骤E2：调用查找到的系统服务接口，完成相应的系统服务功能。

本发明提出的基于形式化规范的服务总线微内核框架设计方法中，所述步骤四中系统服务与硬件交互并返回结果包括以下步骤：

步骤F1：调用的所述系统服务直接与硬件设备交互，完成服务功能；

步骤F2：所述系统服务将硬件处理结果返回给所述事件服务总线；

步骤F3：所述事件服务总线将返回结果编码为通信帧，返回给应用程序。

本发明提出的基于形式化规范的服务总线微内核框架设计方法中，所述步骤五中硬件中断处理包括以下步骤：

步骤G1：事件服务总线接收到硬件中断事件；

步骤G2：事件服务总线根据硬件中断信息在中断向量表中查找对应的中断服务子例程；

步骤G3：调用相应的中断服务子例程完成服务，并返回结果。

本发明提出的基于形式化规范的服务总线微内核框架设计方法，首先对自然语言描述的框架设计规范进行形式化描述，并利用霍尔逻辑将进程间通信原语抽象成形式化规范；然后根据形式化描述，在系统内核中定义处于内核态的事件服务总线，将系统服务移出内核至系统态权限下，以隔离了内核与系统服务；并简化且提供了供用户态应用程序调用的四类通信原语接口，设计了固定帧结构用于通信；在内核中设置服务向量表与中断向量表结构用于实现软硬件中断的事件驱动，同时该框架支持智能设备的中断处理。

本发明以形式化描述为基础，实现基于事件驱动服务总线的微内核框架设计，提高了系统的可靠性，开发的正确性与安全性。

附图说明

图1表示本发明基于形式化规范的服务总线微内核框架设计方法流程图。

图2表示本发明基于服务总线的微内核设计整体框架图。

图3表示本发明的系统权限等级划分示意图。

图4表示本发明应用程序同步调用通信原语与服务总线交互示意图。

图5表示本发明应用程序异步调用通信原语与服务总线交互示意图。

具体实施方式

结合以下具体实施例和附图，对本发明作进一步的详细说明。实施本发明的过程、条件、实验方法等，除以下专门提及的内容之外，均为本领域的普遍知识和公知常识，本发明没有特别限制内容。

如图1所示，是本发明基于形式化规范的服务总线微内核框架设计方法流程图，本发明包括以下步骤：

步骤一：将自然语言描述的框架设计规范进行形式化描述，并利用霍尔逻辑抽象进程间通信原语的形式化规范；

本实施例以此框架设计的进程间通信原语中的CALL原语中的一种返回情况为例，即当输入的服务号参数小于等于0或大于等于最大服务号即服务编码越界时，直接返回-1，利用霍尔逻辑对此进行形式化描述如下：

{service<＝0||service>＝MAX_SVC}NULL{ret＝-1}；

利用霍尔逻辑对四个基本通信原语的全部情况进行形式化描述。

步骤二：根据提取的形式化描述对应设计框架进行开发。

如图2所示的本发明实现在一基于ARM体系结构的开源操作系统中的服务总线微内核设计整体框架图，本发明包括以下步骤：

步骤一：基于微内核架构设计的大体结构，分析操作系统源码，在系统内核中添加事件服务总线的相关数据结构，并在系统内核初始化后开启事件服务总线，事件服务总线采用消息队列的通信机制，事件服务总线不断监听事件消息队列以获取事件。

步骤二：编写处于用户态的内部本地应用程序与外部网络应用程序用以测试进程间通信原语的异步与同步通信机制。

步骤三：基于步骤二编写的用户态应用程序，再根据抽象的形式化规范编写进程间通信原语，以提供给应用程序接口来陷入内核以及编码通信帧来传递数据。

应用程序通过调用本发明的四个基本通信原语实现与系统的交互，体现在代码上便是函数接口，分别为同步发送(CALL)，同步接收(WAIT)，异步发送(SEND)，异步接收(REPLY)。根据抽取的形式化规范实现此四类通信原语函数的主要两部分功能，编码通信帧结构以及陷入内核操作。

通信帧便是应用程序与系统交换数据的数据包，根据不同类型的应用，按照抽取的形式化规范与帧结构的设计编码通信帧结构。

若用户态应用程序为内部本地应用，则在编码事件服务总线通信帧时传递应用程序的端口信息，调用的通信原语类型，调用的系统服务号，通信帧的长度，以及所需传入的数据信息；

若用户态应用程序为外部网络应用，则在编码事件服务总线通信帧时传递应用程序调用的通信原语类型，调用的系统服务号，通信帧的长度，还需传递网络通信中的相关信息，包括发送与确认序列号，网络协议类型，路由跳数，字节序，质量，和多级的源端与目的端的网络地址，以及所需传入的数据信息；

根据选择的ARM体系结构的软中断指令来实现通信原语陷入内核并传递事件服务总线通信帧的功能(此部分可根据不同的体系结构做出更改，此处实现适用于此实例)。

如图4所示的应用程序同步调用通信原语与服务总线交互示意图，示意图中显示了处于用户态的客户端与服务器端两个应用进程通过事件服务总线进行同步通信的过程。

首先，服务器端进程调用同步接收(WAIT)通信原语，事件服务总线接收到通信帧并做挂起服务器端进程等相应处理，使服务器端进程等待目标对象访问。然后客户端进程调用同步发送(CALL)通信原语并传递数据，事件服务总线接收到通信帧并做唤醒对应的服务器端进程(图中的客户端与服务器端进程互为目标与源对象)等相应处理，事件服务总线返回结果给服务器端进程，服务器端进程得到结果后，再调用异步接收(REPLY)通信原语来返回响应。事件服务总线收到通信帧后做相应处理并返回响应给客户端进程，客户端进程在接收到响应之前一直处于等待状态，直到接收到响应后再释放原先发送数据的缓冲区；

如图5所示，是本发明应用程序异步调用通信原语与服务总线交互示意图，示意图中显示了处于用户态的客户端与服务器端两个应用进程通过事件服务总线进行异步通信的过程。

客户端进程先调用同步接收(WAIT)通信原语，事件服务总线接收到通信帧并做挂起客户端进程等相应处理，使客户端进程等待目标对象响应，然后服务器端进程调用异步发送(SEND)通信原语发送数据，之后服务器端进程不处于等待状态，继续自身的进程，事件服务总线接收到通信帧后将服务器端发送来的数据返回给客户端进程，客户端进程接收到数据后调用异步接收(REPLY)通信原语来返回响应，之后客户端进程不处于等待状态，继续自身的进程，事件服务总线接收到通信帧后将响应返回给服务器端进程。

在此实现基础上，用户态的应用程序调用设计的通信原语陷入内核后，设置相应的中断处理函数将通信帧传入事件消息队列。即处于用户态的应用程序调用事件服务总线通信原语接口后陷入内核并将通信帧直接传入内核，处于内核态的事件服务总线直接接收传输来的通信帧，此过程中系统权限由最低权限的用户态经由事件服务总线通信原语陷入后直接切换到系统最高权限内核态。

如图3所示，是本发明的系统权限等级划分示意图。此示意图划分了系统的权限等级，将系统权限划分为用户态，系统态与内核态。其中用户态为最低的系统权限状态，应用程序运行在该系统权限状态之下；内核态为最高的系统权限状态，事件服务总线运行在此系统权限状态之下。系统的其余系统服务，例如系统管理服务，进程管理服务，内存管理服务，网络协议栈，文件系统，设备驱动等则运行在系统态权限状态下。

在服务总线中设置网络事件代理，区别本地事件的处理。则在事件服务总线通过消息队列获取到用户态应用传递来的通信帧后，解码通信帧得知应用程序的类型。若为外部的网络应用则事件服务总线切换到网络服务代理，若应用为内部的本地应用，则不必设置并切换到代理服务，直接进行本地服务处理。

步骤四：基于步骤三事件服务总线解码接收到的通信帧并确定是否切换服务代理处理后，在系统内核里设置一张服务向量表，将操作系统的系统服务处理接口和向量表设置的系统服务号对应(此系统服务向量表根据所用操作系统提供的系统服务可做出更改)，事件服务总线根据解码通信帧得到的相关数据信息确定应用程序调用的事件服务总线通信原语类型，转到相应处理流程。通过通信帧中的服务号信息在服务向量表中查找对应的系统服务，并传入解码通信帧得到数据中的相应参数数据，然后调用对应的系统服务完成相应功能；

步骤五：基于步骤四的事件服务总线调用相应的系统服务后，系统服务直接与硬件交互完成服务功能，事件服务总线得到系统服务返回的服务结果，并对返回数据编码成通信帧，同样设置消息队列将通信帧返回给通信原语的接口层，最后应用程序得到返回结果。

步骤六：对于普通硬件设备产生的硬件中断，在系统内核中设置硬件中断服务向量表，同样设置硬件中断处理函数将硬件中断事件直接发送给事件服务总线，事件服务总线接收到硬件中断后根据硬件中断向量表调用相关中断服务子例程，然后返回结果给事件服务总线，事件服务总线再将硬件中断处理结果返回给应用程序。对于智能硬件设备产生的硬件中断，则由设备自带的控制器处理中断，只需给事件服务总线发送一个通知即可，然后调用相关中断服务子例程完成服务，并返回结果。

本实例以基于ARM体系结构的开源操作系统为例，首先对自然语言描述的框架设计规范进行形式化描述，并利用霍尔逻辑对进程间通信原语进行形式化抽象，再根据得到的形式化规范对其内核代码进行修改，在操作系统微内核大体框架上实现本发明基于形式化规范的服务总线微内核框架设计方法。实现后的系统内核简化为事件服务总线，可用于实现事件驱动和线程切换的功能，在此基础上，以后还可以进一步完善事件服务总线以实现安全验证的功能。同时提供了供应用程序调用的四类通信原语接口，实现同步与异步通信。在内核中还设置了系统服务向量表与中断向量表，使事件服务总线处理接收到的软硬中断事件，并支持智能设备的中断处理响应。本实例所实现的基于形式化规范的服务总线微内核框架设计方法，有助于进一步提高系统的可靠性，以及系统的安全性与开发的正确性。

本发明的保护内容不局限于以上实施例。在不背离发明构思的精神和范围下，本领域技术人员能够想到的变化和优点都被包括在本发明中，并且以所附的权利要求书为保护范围。

Claims (9)

1.一种基于形式化规范的服务总线微内核框架设计方法，其特征在于，包括以下步骤：

步骤一：对自然语言规范进行形式化描述，并利用霍尔逻辑抽象进程间通信原语的形式化规范；

步骤二：基于所述形式化描述开发设计框架，在微内核框架中定义事件服务总线，事件服务总线直接接收通过进程间通信原语陷入内核的事件，并根据获取的数据决定切换到网络服务代理或本地服务处理；

步骤三：所述事件服务总线根据获取的服务号查找对应系统服务，并调用所述系统服务完成相应功能；

步骤四；所述系统服务直接与硬件交互，并返回结果；

步骤五：若为普通硬件设备产生的硬件中断，由事件服务总线处理硬件中断，事件服务总线调用系统服务完成中断处理，并将处理结果返回给应用程序；若为智能硬件设备产生的硬件中断，则由设备自带的控制器处理中断，然后直接调用相关中断服务子例程完成服务，并将处理结果返回给应用程序。

2.如权利要求1所述的基于形式化规范的服务总线微内核框架设计方法，其特征在于，所述步骤二中，在微内核框架中定义事件服务总线包括以下步骤：

步骤A1：在微内核中添加事件服务总线的数据结构；

步骤A2：在所述微内核初始化后直接开启所述事件服务总线。

3.如权利要求2所述的基于形式化规范的服务总线微内核框架设计方法中，其特征在于，所述事件服务总线采用消息队列的通信机制，所述事件服务总线不断监听事件消息队列以获取事件。

4.如权利要求1所述的基于形式化规范的服务总线微内核框架设计方法，所述步骤二中，事件服务总线直接接收通过进程间通讯原语陷入内核的事件包括以下步骤：

步骤B1：用户态的应用程序调用进程间通信原语接口陷入内核，并通过编码通信帧传递数据；

步骤B2：内核态的事件服务总线直接接收到通信帧，且系统权限由用户态直接切换到内核态。

5.如权利要求4所述的基于形式化规范的服务总线微内核框架设计方法，所述步骤B1中编码通信帧包括以下步骤：

步骤C1:若用户态的应用程序为内部本地应用，则在编码事件服务总线通信帧时传递应用程序的端口信息，调用的通信原语类型，调用的系统服务号，通信帧的长度，以及所需传入的数据信息；

步骤C2：若用户态的应用程序为外部网络应用，则在编码事件服务总线通信帧时传递应用程序调用的通信原语类型、调用的系统服务号、通信帧的长度和传递网络通信中的相关信息，所述相关信息包括：发送与确认序列号、网络协议类型、路由跳数、字节序、质量和多级的源端与目的端的网络地址，以及所需传入的数据信息。

6.如权利要求1所述的基于形式化规范的服务总线微内核框架设计方法，其特征在于，所述步骤二中，根据获取的数据决定切换到网络服务代理或本地服务处理总线包括以下步骤：

步骤D1：解码通信帧得到数据信息，并根据通信帧的长度信息判断应用程序类型；

步骤D2：若应用程序为外部的网络应用则事件服务总线切换到对应的网络服务代理；

步骤D3：若应用程序为内部的本地应用，则直接进行本地服务处理。

7.如权利要求1所述的基于形式化规范的服务总线微内核框架设计方法，其特征在于，所述步骤三中查找、调用并完成相应系统服务功能包括以下步骤：

步骤E1：根据解码通信帧得到的服务号在服务向量表中查找对应的系统服务；

步骤E2：调用查找到的系统服务接口，完成相应的系统服务功能。

8.如权利要求1的所述基于形式化规范的服务总线微内核框架设计方法，其特征在于，所述步骤四包括以下步骤：

步骤F1：调用的所述系统服务直接与硬件设备交互，完成服务功能；

步骤F2：所述系统服务将硬件处理结果返回给所述事件服务总线；

步骤F3：所述事件服务总线将返回结果编码为通信帧，返回给应用程序。

9.如权利要求1的所述基于形式化规范的服务总线微内核框架设计方法，其特征在于，所述步骤五中，事件服务总线处理硬件设备的硬件中断包括以下步骤：

步骤G1：事件服务总线接收到硬件中断事件；

步骤G2：事件服务总线根据硬件中断信息在中断向量表中查找对应的中断服务子例程；

步骤G3：调用相应的中断服务子例程完成服务，并返回结果。

Images