1 嵌入式操作系统配置通用化模型
以操作系统抽象模块作为操作系统配置的基本单位,在此基础上得到了嵌入式操作系统配置通用化模型OSCFG。
1.1 模型概述
如图1所示,虚线框表示建立的操作系统配置模型。左边的两个实线框表示对于操作系统配置模型的输入:选择配置的操作系统类型和选择配置的操作系统抽象模块。右边的实线框表示输出的配置生成结果:特定的配置文件。
操作系统配置模型的关键在于通用性,即对不同的操作系统,能够在逻辑上对操作系统所划分出来的物理模块保持透明性,因而,建模要点在于以下两点:
①对各式各样的操作系统模块进行抽象,使之成为对应于配置模型的抽象模块。抽象模块以模块属性文件的形式存放在构件库,供配置选用。
②抽象模块最后能映射为对应于不同操作系统的实体信息。
在上述前提下,构建了如图2所示的操作系统配置过程模型 OSTAILOR。图中阴影部分实现了配置的操作系统无关性,可以称为操作系统抽象层。 图2 O$1AII一0R过程模型对于具体的操作系统模块实体,首先经过模块抽象,封装成对应用可见的操作系统抽象模块。每一个操作系统模块包含两个关键属性:①抽象出来的模块名。根据此模块名,应用开发人员可以知道此操作系统模块具有的基本功能。②模块层次,隶属于不同层次的模块具有不同的模块粒度。一般而言,越靠近底层的模块,粒度越细。在配置完成以后,根据用户输入选择需要映射的特定操作系统,根据此输入选择,模块配置完成以后,才能选择特定的操作系统映射算法将抽象的模块映射到具体的操作系统功能上。
图2中抽象模块配置层完成的功能还包括可根据用户选择,将操作系统抽象模块配置成更高层次,更大粒度的模块,供本次操作系统生成或下次定制使用。在这个操作系统定制模型中,抽象模块配置层以下层次完成的功能是根据模块配置层的配置结果和用户对操作系统类型的选择,完成对具体操作系统的映射。这部分因为与具体嵌入式操作系统相关,因而具有特殊性。为了实现配置的通用性,也就需要考虑如何把特殊性降低到最小。
1.2基本工作原理
1.2.1配置基本流程
定制的基本流程如图3所示。用户浏览器查询构件库,并对用户显示出可选模块,然后接收用户对模块的选择,将选择结果送至文件解析器。从构件库获得对应模块的属性文件。通过解析,将解析结果生成模块结构映射关系图。模块结构关系图中的模块均以抽象逻辑形式存在,可以通过查找构件库得到它以文件形式存在物理实体信息。根据模块结构映射关系图和每一个模块的物理实体信息。生成对应的Makefile或其它一些相关配置文件,把它提供给对应的Make工具(编译器、链接器等),最后生成系统的可执行文件。
1.2.2模块抽象的层次划分
一般说来,模块的粒度越大,每一个模块所包含的功能越多,其可配置性就越低;而模块粒度越小,配置复杂度越高〔5〕。为了达到配置的灵活性和方便性,并将配置中涉及到操作系统特殊性的地方降到最小,我们将模块抽象出来,并将其划分为多级结构,不同层次的模块封装其下层模块,形成不同的配置粒度。现以3层结构进行描述,如图4所示。
图4中最下层是原子级模块,它抽象了操作系统的基本功能,包括任务(task)、I/O驱动(driver)、定时器(timel)、信号量(sernaphore)、消息队列(quecue)、事件(event group)、邮箱(mailBox)、管道(pipe)等。除此之外,还包括一些基本的应用功能。之所以取名为原子级模块,是为了表明它是不可再分的基本模块,是配置其它层次模块的基础。
原子级模块的粒度存在于目标代码或库文件级,因为它映射的物理实体以目标代码或库文件存在。虽然在图4的层次结构中,它也是作为抽象的逻辑模块存在,但是它是和物理实体联系最紧密的一层,也是模块粒度最细的一层。因而在配置过程结束以后,通过这层映射到不同的文件,产生不同格式的配置文件,达到配置不同操作系统的目的。原子级模块完成的只是某一特定功能的一部分,或者只是某一特定功能一个子功能,必须和其它原子级模块相结台才能发挥应有的作用。因而在它的上层提出了功能级模块的概念。
功能级模块由原子级模块配置生成。通过把不同的原子级模块结合在一起,完成某一特定功能,并加大了模块粒度。例如,配置无线上网的功能模块,除了要选择无线上网本身这个原子级模块,还需要选择操作系统中支持上网功能的原子级模块,比如TCP/IP协议栈。
通过把功能级模块组装在一起,完成更强大的功能,就构成了应用级模块。每一个应用级模块都是一个功能模块集,也是粒度最大的一层模块。对于应用程序开发者,为了开发特定的应用程序,如果不想选择细粒度的模块,可以直接选择应用级模块来配置操作系统。
这种模块化的分层结构,能为开发者提供不同的模块粒度,使用户可以根据需要,选择不同层次的模块,以便增强定制过程的灵活性;而其最大的优点是,对于每一次定制需求的改变,不必由最细粒度的原子级模块配置重新做起,而是可以对需求改变进行分析,替换掉恰当粒度的模块,保持其它部分不变,简化了配置过程,减少了配置时间。
1.2.3模块层次的解析
模块解析和模块配置过程正好相反。模块配置是从最底层开始,逐层构建出高层模块;而模块解析则从最上层开始,层层向下,直到寻找到最下层的映射关系,同时构造出对应的关系图。
基于对模块的封装,每层模块只关心和它紧密联系的下层模块的映射关系,即它是由下层的什么模块所构成的。为此,我们在配置生成每一个模块时,将它对下层的映射关系保存在数据库中。
逐层解析时,我们把模块名作为关系图的顶层结点,并在数据库中查找它对下层模块的映射关系。根据映射关系中涉及的下层模块,如果关系图中不存在它对应的结点,在关系图中添加新的结点,每个新结点对应一个下层模块名。根据映射关系,添加图中的拓扑关系。再将每个新结点作为一个新的顶层结点,重复刚才的过程,直至最终映射到原子级构件,则构造出一个完整的关系图。可以说,关系图生成的过程也就是整个映射的过程。算法描述如图5所示。
1.2.4配置的最终完成
到模块层次解析过程完成为止,所有的操作均屏了操作系统的特殊性;但嵌入式系统是多样的,不仅体现在操作系统的多样性上,而且,即使相同的操作系统,对应不同的处理器,其组成也是千差万别的。为了生成用户定制的具体操作系统,根据用户输入选择的操作系统类型,在上面解析处理生成的关系图中,选择出度为O的结点(即为原子级模块对应的结点)映射到不同的操作系统实体,再根据不同编译器、链接器能识别的规则,生成不同的makefile文件、config文件和资源文件。可以说,各种配置文件的生成标志着操作系统定制过程的完成。
2 基于嵌入式Linux的配置剪裁器的实现
使用定制过程的通用模型,我们实现了一个嵌入式Linux的配置剪裁器。该配置剪裁器作为一个工具集成到基于嵌入式Linux的PDA手机开发平台中。配置剪裁器使用构件库管理器作为其可选抽象模块的容器,而其输出的配置文件则提供给项目管理器,由后者提交给编译器和链接器进行操作系统生成。三者的关系如图6所示。
下面是三个工具的功能说明。
(1)配置剪裁器
①显示从构件库获得的已有模块信息。
②根据用户选择,配置新的模块,并将模块信息存入构件库,供下次定制时作为已有模块使用。
③定制特定应用开发所需的操作系统:用户可以选择构件库中已存在的不同粒度的模块进行配置。在需要编译连接生成可下载到目标机的目标代码时,生成对应的配置文件,传给项目管理器。
(2)构件库管理器
保存操作系统抽象模块信息,供配置剪裁器查询和使用。查询内容包括:①可以配置的模块名,供配置剪裁器提取出显示在用户界面上,供用户配置选择;②每个模块对它下一层的映射信息。根据此映射信息,可以进行递归往下查找,因而支持配置剪裁器中对每个模块的层次解析和操作系统映射功能。
(3)项目管理器
项目管理器管理应用程序的开发,因而项目管理器向配置剪裁器提供应用开发者编制的应用程序的源文件路径信息。嵌入式软件的最大特点就是应用程序往往不是独立存在的,它最终和操作系统一道作为二进制目标代码下载到目标机。所以,配置剪裁器需把从项目管理器获得的源文件路径信息写入对应的Makefile文件中。
以用户的应用程序开发配置所需的应用级模块为例,将配置剪裁器工作步骤说明如下:
①选择构件库中已有的应用级模块,定制操作系统,将配置文件路径保存在构件库管理器中。
②当收到项目管理器获得具体操作系统配置文件的请求时,查找构件库,得到保存的特定应用的配置文件路径。根据此路径和文件名,打开文件进行解析,获得应用所包含的应用级模块的个数和模块名,生成初始的关系图。
③根据应用级模块的个数和模块名,查找构件库,得到每个应用级模块的配置文件名和路径。解析文件得到对应的功能级模块,将功能级模块和对应拓扑关系添加在关系图中。
④以此类推,直到找到对应的原子级模块,最终生成一个完整的关系图。
⑤根据关系图查找构件库,把原子级模块映射到定制的操作系统实体上。本系统利用Linux自带配置系统,通过修改Linux的源码系统中已有的Makefile和kconfig文件,来编译内核,生成用户定制的操作系统内核。因此原子级模块对应于特定操作系统的实体信息就是kconfig文件中需添加的配置项,如选择了网络模块对应的实体信息,即“CONFIG_NET=y”配置项。
结语
通过对操作系统定制技术进行研究,抽象出操作系统定制过程通用模型OSTAILOR,并结合863项目“面向PDA手机的嵌入式软件开发平台”实现了一个嵌入式Linux的配置剪裁器。用户可以使用本工具友好的图形化界面对Linux内核组件及应用模块进行操作系统定制,自动生成各种配置中间文件,避免了手工编写修改这些文件的繁琐,从而演示了使用此模型来实现嵌入式操作系统定制过程的通用化的可行性。但是在本模型中,应用开发者定制了特定的操作系统,就必须使用该操作系统提供的应用编程接口(API)。若需修改定制的操作系统,就必须替换应用程序中对应的API。如何在操作系统定制过程中,满足应用开发的操作系统无关性,将是本课题进一步研究的方向。