|
|
|
“应用的即插即用”型操作系统解析
——“操作系统构建学”原理及构建示例
（第一版）
作者：孙海勇
前言
夜很静，硬盘的读盘声音显的十分的干脆，一行行正在编译的信息在屏幕上流动，我切换了屏幕，开始享受轻柔的音乐，开始思考刚刚遇到的一些问题，突然间我问我自己，这几年沉醉在源代码制作系统的过程中究竟为了什么？
也许我有办法构建出一个具有独特体验效果的系统，又或许我可以研究系统构建中的理论从而掌握其中的内在规律。
我有时候在想，也许该有一门“操作系统构建学”，或许我该创建它，我也能成为一门学科的开山鼻祖。哈哈！
那么为了我的想法，我决定走出第一步，首先我提出“操作系统构建学”，然后不断的完善它。
“操作系统构建学”研究的方向是如何科学的构建一个符合应用要求的系统，研究的主题是系统组成方式以及分析组成系统的各要素的实现方法。
“操作系统构建学”是以实践为目标的，通过实践的过程整理和完善出规律性的东西，通过这些规律性的东西来帮助构建更加科学的系统。
好了，那么我就献上我对于“操作系统构建学”第一篇正式的文章。
场景
我打开了我的计算机，启动好的桌面上几乎没有东西，整个系统似乎什么都没有安装……，我拿出了我已经准备好的一个U盘，轻轻的插在计算机上，两、三秒后，我的桌面上出现了丰富多彩的各类图标，有办公的、有听音乐的还有许多游戏，我开始播放音乐、写着我的文章……，我想出去运动一下了，我保存了我的文档、关闭了音乐，拔下U盘，一瞬间，桌面上所有之前冒出来的图标都消失了，一切都像什么也没有发生一样……，我关上了计算机，跑步去咯！:-)
写在前面
本文并非操作手册，而是一篇原理性的探索文章，然后将我自己一些原创的想法写出来供人参考的文章，既然是想法那么就会有认同的人也会有不认同的，我把我的想法写出来是为了进行交流，欢迎任何想进行真诚交流的朋友，不管是支持的还是反对的，有兴趣的朋友可以来我的blog：youbest.cublog.cn，也可以给我发邮件：[EMAIL="youbest@sina.com"]youbest@sina.com[/EMAIL]
为了更能具有说服力，我制作了一个演示系统，有兴趣的可以从我的blog上看《“应用的即插即用”型操作系统演示系统下载》
孙海勇
开门见山
首先看一张图，这张图就是本文要讲的系统模型的结构图：
其中蓝色部分我把它称为“弱依赖关系的基础系统”，我把整个结构称为“应用程序的即插即用”系统模型图。
文章开头的一段场景描述就是这种“应用程序的即插即用”系统的使用体验，当然这只是这种系统的一种使用方式，系统设计人员完全可以根据具体的使用情况来改进使用方式或者变化用户的体验方式，比如笔记本和手持设备，有屏幕和没屏幕的设备的使用方式和用户体验方式可能是完全不同的。
在开始讲述这种“应用程序的即插即用”系统之前，我想把我对“操作系统”构成要素的理解先谈一下。
上篇——“操作系统构建学”原理
作为开发系统的人请先问自己一个问题：用户为什么要用你设计提供的系统？
带着这个问题，看看我们能否从“操作系统”的各组成要素中寻找突破口呢？
“操作系统”的组成要素
把之前的结构图抽象化一下
这个就是通常意义上的操作系统模型：它包括了基础系统、组件管理器、用户界面、应用程序集合、开发环境、用户、服务七大要素。
一、 基础系统——系统的根基
定义：
这里我把基本系统定义为集合了一组基础功能及各种运行库并可以启动的系统。
要求：
基础系统对在其上运行的应用程序具有支持其运做的能力，并且符合系统本身一些必须要满足的特殊或特定需求，系统的启动也必须符合系统实现要求。
原则：设计不要求面面具到，也不能绝对否定
世界上没有完美的东西，如果你要求你的基础系统是面面俱到的，那么你会发现你永远也没办法完成这个系统，“舍”“得”要权衡；基础系统制定中也不能认为什么绝对不会用上，但是根据情况我们可以判断某些不重要或者暂时不重要，是可以不包含在其中的，根据今后的需要也可能增加进去。
不同目标的系统中的基础系统要素的构建方法并不是完全一样的，这个需要根据具体的要求来制定建议的构建方式和方法。
一个系统的基础系统定制的合适不合适直接影响整个系统的可靠性、复杂性和可维护性，所以必须高度关注。
对于一个基本系统的启动方式是一个值得挖掘的地方，合适的启动方式是基础系统所应该追求的目标，启动方式的设计不仅需要考虑如何使系统处于预先确定需要达到的准备状态和启动要求，更要考虑基础系统本身的存放方式对启动过程的影响。
一个实际的基础系统往往会包含一些应用组件，这些应用组件的包含可以保证基础系统满足一些规则，如字符集的支持，以及对于一些必须的需求的实现，比如安全的支持。
因此对于基础系统，设计人员要分析特定要求、需要包含的内容和启动的设计。
没有良好的基础，怎么盖高楼大厦？
二、 应用程序——系统的主体
应用程序用于满足用户对于功能的需求，对于一些必须的规则及基础功能的实现也归于应用程序。
一根木棍，给它扎上布条，就能当拖把使，给它装上个钩子能当挂衣钩，木棍还是木棍，拿它干什么用看你给它装了什么。
对于计算机里运行的软件，用户最关心的是什么？
如果问用户关心的是什么，也许回答会非常的多：速度、界面、功能、可操作性、使用习惯……
如果在问题中加一个最，那么是什么呢？这个仁者见仁、智者见智，但我的选择是：功能。
用户使用软件的目的是什么？实现他的目的，无论他是想上网、写文章、听音乐、娱乐、玩游戏，实现这些的软件必须要具备的就是实现这些目的的功能。如果实现不了这些功能，那么你的软件就是速度再快、界面再好看也是没有用处的。
所以用户需要的是功能而不是软件本身，打个比方如果为了卖荧光灯而卖荧光灯，可能你一直卖的都是荧光灯，如果你的客户需要的某种情况下的照明功能，那么也许可以选择发光二极管制作的灯？呵呵，这里我尝试写下一个公式：需求＋软件=功能
问题：M软件曾统治相关领域若干年，现在W软件不管界面、操作以及软件本身的功能上都和M软件非常像，但是W软件和M软件所产生的文件兼容性不好，导致W软件始终很难取代M软件，既然功能上没什么差别为什么难以取代呢？（此问题不带有任何产品的偏向，只是为了方便阐述思路）
这样的问题通常会被归结为用户习惯问题，但是在分析两者的区别时，我们发现M软件由于统治相关领域若干年，这样就导致了大量历史文件，这个时候我们在分析用户需求的时候需要注意一个隐含的功能需求“能够正确打开以前保存的文件和他人发送过来的文件”，这说明其实W软件并没有真正的满足用户对功能的要求，如果想满足用户对功能的需求，那么两种方法：实现这个隐含的功能需求或者使用户不再有这样的功能需求。
那么一个系统之所以被用户认为有用，最核心的原因是在这个系统中可以运行的应用程序能满足他们的功能需求。
对于应用程序能否正常的运做最重要的因素就是“基础系统”，只有能和“基础系统”良好对接的程序才能称为应用程序。
在我们现在常用的系统里无非两种对接，一种是在给用户使用之前就对接好了（预装或者绑定的软件），另一种是用户自己去对接（用户下载软件并安装软件）。一般来说把用户自己去对接的方式分为主动知情的、主动不知情的、被动知情的和被动不知情的四种对接方式。主动知情是用户想装且知道自己在装什么，主动不知情是用户主动安装了软件但确不知道是什么功能的软件被安装了，被动知情是用户不知道安装一个他需要的功能，被动不知情是用户不知道安装了不需要的功能。
需要说明的是对于用户的同一次对接可能存在多种对接方式，一样的对接对于不同的用户可能是不同的对接方式。
因此对于应用程序，设计人员需要仔细详尽的分析用户的功能需求和按照你需要运行的基础系统所规定的方式进行对接设计。
何不把自己当成用户？去挖掘用户的需求吧！
没有好的应用的系统能算是一个好系统吗？
三、 组件管理器——系统的对接器
木棍上的布条是拿绳子扎，还是拿胶水粘，或者是那钉子钉上去？
组件管理器的作用对接和定位。
对接就是保证基础系统和应用程序良好的进行衔接使其成为一体，如何对接，用什么对接，这个取决于你要实现的系统使用应用程序的方式。对接功能同时也包含了如何解除连接的方式。
有的时候组件管理器的对接功能可以将其包含进基础系统中，也可以转移到应用程序本身，甚至可能被包含进用户界面系统中，但作为整体系统的组成要素其设计要单独细致的考虑。
组件管理器的另一个重要功能是定位应用程序的位置，应用程序的位置可以是一个存储在本地固定存储装置中、可以是一个移动的存储装置、网络存储设备、甚至可以是一个用户都不知道具体地理位置的公共网络某个或多个站点上，组件管理器要帮助系统运行应用程序时能够正确的找到它。
组件管理器可以以多种形式来实现，它可以是一个具体的程序，也可以是一种特制的文件系统，甚至它可以只是一种规则。
组件管理器的一头是基础系统，另一头是应用程序，好的组件管理器可以轻松的将两者紧密而稳固的连接起来，也可以轻松的不破坏任何东西的情况下将应用程序从系统中分离开。
在很多时候组件管理器的功能是被包含进基础系统中的，甚至用组件管理器去管理基础系统本身（将基础系统本身看作是若干不同的组件，但终究可以找到其中之一作为基础系统），在实际逻辑结构上基础系统和组件管理器是两个要素。
因此对于组件管理器，设计人员需要考虑的不仅仅是如何把应用和系统对接使其正常运行，同样重要的是需要考虑如何把应用从系统中分离开。
设计好这样的东西真是一种挑战，它的重要性决不亚于它连接的二者。
四、 用户界面——系统的脸面
这里的用户界面表示的是可以与用户进行交互的操作方式或者接口，这种方式可以是图形、文本也可以是声音，亦或只是信号灯，总之只要能被人接受到并可以将用户的意图传递给计算机的方式都可以称为用户界面。
用户界面直接与用户进行交互，在一定程度上对于用户来说界面就代表了这个系统本身，所以对于不同使用情况下的用户必须采用合适的表现方式。
合适的用户界面可以给人一种亲切的感觉，精心设计的接口总是提高使用效率的良策，它的重要性不容质疑，设计好它需要的不仅仅是技术还有艺术。
因此对于用户界面，设计人员首先要考虑是如何传递用户的意图以及表达系统的反馈，人性化的表现力和资源的占用要有合理的定位。
谁不喜欢养眼的面孔？:-)
五、 用户——系统的核心
用户是需求的提出者，对于用户的需求可以分为两个类型，显性的需求和隐性的需求。显性的需求一般表示用户提出的需求，隐性的需求是指用户知道但没有明确提出，或者用户自身未察觉到的需求。
隐性需求的挖掘是系统创新的源泉。系统问题的突破往往在于对隐性需求的探索，在用户要素中出现了冲突的功能需求，可以尝试去挖掘隐性需求来解决。
这个要素部分需要关注的不仅仅是用户本身，你需要把用户当成一个系统来看待，你更需要额外的关注用户所处的外围因素对用户功能需求所产生的影响，以及寻找用户所处环境中能帮助用户系统发展和完善的要素。
作为系统核心——用户，我们首先应该分析用户对于这个系统的期望是如何的，如果条件允许就是让他们来参与你的设计。
如果用户是残疾人，你不可以以健全人标准来要求他们，设计的时候请考虑他们的难处。
我相信现在越来越多的设计人员将用户放在一个重要的位置，但是有多少人是把用户作为系统的一个重要组成来看待的？我这里不做调查也不做任何评判。
如果你希望你的系统能得到用户的认可，请你把用户作为你系统的一个重要的要素来考虑，不要把他们排除在系统的外面仅仅作为一个看客。
这里将用户分为两个类别：开发用户和应用用户。这两中用户类别所关注的东西并不一样，开发用户通常关注的是用户要素本身的发展，而应用用户关注的是除自身外其它要素的发展，但在行为上开发用户更多的是发展除用户要素之外的其它要素，而应用用户更多的是发展用户要素自身。因此要想系统良好的持续发展必须对这两类用户同样的重视。
这里要注意的是虽然用户被分为了两类，但对某一具体的用户来讲，他可能既是开发用户也是应用用户。
要把用户当成系统的一部分，从自身做起，把自己作为一个真正的用户，以用户的角度去想，以用户的角度去看待。
用户都是希望把他作为自己人来看待。
六、 开发环境——系统的土壤
开发环境看来是给开发用户最重要的一环了，一个系统的目的是为了给用户提供需要的功能，各种各样的功能都是靠开发者一点一滴开发出来的，要想让开发者能够顺利的开发用于系统之上的各种功能，良好的开发环境是必须具备的要素。
开发环境包含了：编译套件和系统开发引导。
开发环境的设计需要考虑开发用户本身所处于的开发环境，这可能需要涉及到提供跨平台的开发环境，同时要考虑开发用户对于整个系统的认知程度。
编译套件只是提供开发的工具，光有工具是不够的，更需要的是指导，通过诸如提供开发手册、开发规范、开发示例等对开发用户起到引导和帮助的作用。
因此对于开发环境，编译套件固然不可缺少，但设计人员着重要考虑的是如何引导和帮助开发人员。
“我的开发能让更多的人用上。”几乎是每个开发人员的想法。
七、 服务——系统的活力源泉
服务是为了疏通要素之间的信息传递，使系统中的要素健康有续的不断发展、不断完善的方法和手段。
服务的本质就是持续改进。
服务的目的是使系统内生态平衡发展和外生态协调发展。系统内生态是指系统内各要素的相互关系，系统外生态指系统所处于的更大的系统环境与本系统的相互关系。
服务将用户要素的反馈信息传递给其它要素及自身，不断帮助要素进行改善升级，同时这些要素的改善和升级反过来促进用户要素的提升。比如对于应用程序要素，缺陷报告机制作为服务的一项内容，服务要素反馈用户的信息有助其进行升级，升级后的应用程序帮助用户提高完成任务的能力，从而使用户要素得到发展。
再比如为了使用户系统不断发展和完善，可以提供合适、齐备的用户手册及文档，使用户不断的了解系统，帮助用户这个要素不断的发展（如：人数扩大）和完善（如：应用能力越来越强）起来，而用户要素发展必会反馈信息给其它要素，其它要素根据信息来调节自身不断的完善发展。
服务是各要素的营养输送者，发达而有效的服务要素将促进系统的成长。
因此对于服务要素，根据服务的本质和目的考虑如何实现持续不断的改进包括自身在内的所有要素的方法，使它们协调发展。
服务是一个动态的要素，要持续不断的进行服务的过程才能疏通经络，保持系统的活力。
我想说：一个好的系统难以靠个人的力量开发出来。一个好的系统要把所有的要素同等的用心对待。
现在根据前面阐述的七大要素新绘制了一个关系图，我把它称为“系统七要素梅花图”
如果把这个系统比作某种动物，那么
基础系统——骨架
应用程序——肌肉
用户界面——外形、皮肤
组件管理器——神经组织
开发环境——内脏器官
服务——血液
用户——大脑
骨架使身体得以支持，肌肉使身体拥有了力量也使身体有了更多的能力，合适的外形便于生存，神经组织让整个身体协调运动，内脏器官给了身体源源不断的动力，血液的循环使得整个肌体充满了活力，大脑则指挥着身体奔向未来。
下篇——“应用的即插即用”型操作系统
好了，上篇中进行了七要素分析，我们来做个尝试——如何实现这样的系统：应用软件即插即用、整体系统不需要包管理器（或者称为包管理器的无关性）、弱依赖关系的应用系统。
两点说明：
1、 为了讲解方便，我采用制作一个GNU/Linux系统做为示例，但是这种系统的实现并不局限于GNU/Linux。
2、 因为目标是制作应用软件即插即用、弱依赖关系的操作系统，这本身就是一个大工程，这样的系统本身是实现的，但涉及的细节过多，为了方便理论联系实际本文采用设计一个非常小型的系统来作为演示，其文章整体思路并不局限于这个小型系统，是完全适用于制作一个该类型较大的通用系统。
如果把上篇中的“梅花图”对应到本文所描述的特定的系统模型
这个就是本文要描述的一个具体的系统模型。
为了让文章看起来不是那么的枯燥，我会在整体讲述过程中穿插起一个制作一款简单的支持“即插即用的应用程序”的系统，而作为示例的应用我会实现一个音乐播放功能的应用来进行展示。
开始分析各个要素前，根据要求问自己一个问题：用户为什么要用我提供的系统？
我提供的系统使用了一种“即插即用”的应用程序使用方式，这不同于目前大多数操作系统使用应用软件的主要方法。比如用户可以通过这样的系统把自己喜欢的软件放在U上然后可以在使用了相同的系统上直接将U盘插在机器上就能立刻使用U盘上的软件了，不需要再把软件安装在系统里才能使用（当然系统里一样可以安装各种软件），也可以保护系统不会安装太多的东西，实现了软件随身带，即插即可用的目的。
一、 用户
挖掘用户的隐性需求，用户可能需要一个方便安装和卸载功能的方式使用应用程序。对于开发用户他可能会在关心应用程序使用方式的同时关心应用程序该如何配合这样的功能；应用用户关心的更多的是这样的系统是否容易上手，相应的应用程序如何得到？
分析这个部分的时候关注的不仅是用户自身的需求，他所处的环境对其可能产生的需求也要进行分析。
用户上网是否方便？现在Ｕ盘对用户来说是否是普遍都拥有的？U盘通常使用的文件系统是什么？等等……
分析本系统，要制作的是一个通用系统，用户人群为一般的应用用户，用户可能使用会使用U盘或者其它什么移动存储装载应用程序，部分用户上网也会比较方便，用户可能会利用其它机器的操作系统来下载应用程序到移动盘上，这些移动盘通常可能使用的FAT格式。
这里我要完成一个能够作为我这篇文章的示例系统，那么我分析的用户自然是本文的读者，我定位为应用用户，用户的目标应该是想通过我做的这个演示系统来对本文有一个感性的认识，当然个别用户会尝试制作一个事例来更深入的了解一下本文。
我可以列举一些需求来帮助我对后面的系统要素进行分析。
目前多数用户相对来说上网方便，大多数容易拥有U盘，Ｕ盘的文件系统通常是FAT，有Windows或者Linux的使用经验。
我这个系统的用户也许就是你！
二、 即插即用的应用程序
这部分也许是本文最核心的一处概念。
什么是“即插即用的应用程序”？
如同本文的上篇中描述的一个场景，当我把U盘插在计算机上，立刻计算机系统就发现我的U盘上有我想用的程序，并立刻在用户界面上显示出来。即插即用的概念就是平时我的应用程序是放在我的U盘里的，只在我需要的时候将U盘插在计算机上就可以和我的计算机中的操作系统进行对接，对接后立刻就能使用Ｕ盘上面的应用程序，拔掉U盘应用程序就从我的操作系统中断开了，对我的操作系统没有任何影响。如果其它地方的机器和我用的一样的系统，那么我把U盘插上去也立刻可以开始使用了，不会在我家里使用着我自己熟悉的软件而到里其它地方不得不去使用对我来说可能陌生的软件。
分析本系统，既然打算做通用型的系统，那么对于应用程序的功能的需求是多种多样的，如何获得这样的程序，以及如何去让这些应用程序符合本系统的要求。
如果我们制作的是开源产品的系统，那么很多程序几乎不需要修改或者只要修改很少的部分就能达到系统要求，支持应用程序的数量将随着系统的成长逐渐发展。
对于我即将制作的演示系统中应用程序的分析：
既然我要实现的是“即插即用的应用程序”，用户是读者，本身并不会去长期使用这样的演示系统，那么演示系统要求能演示，对具体演示的内容并不是太重要，不需要占太多的时间和空间。
那么要满足的功能需求是：演示和即插即用的小程序。
我将准备好一个音乐播放的小型软件。
三、 弱依赖关系的基础系统
既然是应用程序即插既用的系统，那么我的基础系统应该满足应用程序的一些基本要求，但说实话如果你不能确定需要用的应用程序是什么你可能很难做出决定该将什么样的东西包含进基础系统里，东西放多了当然不会造成太多的问题，但是可能导致系统的臃肿，特别是在一些空间容量不太大的系统中，东西放少了则可能导致应用程序为了能运行增加自带的部件，如果几个应用程序恰好都带了相同的部件则导致部件的冗余，也使应用程序显得臃肿。
构建这样一个“弱依赖关系的基础系统”的原则是：不能绝对化。
什么东西需要什么不需要什么一定要实际情况实际分析，不能照搬照套。
构造出这样一个适合的“弱依赖关系的基础系统”究竟包含一些什么还是可以找出一些方法的，基础系统一般可以考虑包含下列部分（非充要条件）：
１、常用硬件的设备驱动及为了驱动这些设备所必须的支持组件
系统将会运行在什么样的设备上，会出现什么样的设备会连接到我们的系统上要进行详细的分析，如果设备很专一或者很特定那么我们对硬件的支持完全可以做到只放必要的设备驱动即可，不需要任何多余的驱动。
如果我们的硬件设备上没有网卡没有声卡，那么我们完全可以不用任何网卡及声卡的驱动
２、各种系统所需常规文件系统的支持组件
现在的文件系统琳琅满目，是不是都需要分析一下你的应用环境。
３、各种系统所需常规文件类型的支持组件
如果你的设备可以进行图象的输出，基本系统里提供常规的图形文件格式的支持组件还是有极大的可能用的上；没有声音输出需求的设备如果放一堆音频格式的支持库似乎只能是浪费存储空间。
４、各种系统所需常规协议的支持组件
如果是个网络设备，各种网络协议可是不能缺少的。协议可以被看做两个不同的组件之间的交流方式，这当然不局限于网络上。
５、为用户界面所提供支持的组件
分析本系统，现在设计一个支持“应用的即插即用”方式的通用基本系统，下面这个图也许可以作为一个参考。
基础系统的设计人员也可以根据系统的情况自己制定一些包含内容的规则，比如有10个以上确认可用的应用程序使用了相同的基础库，那么就将在基础系统中加入这个库。
如何建造这样的系统
创建这样的系统并不是一件复杂的事情，我们可以有多种手段来创建它，如果我们采用GNU/Linux来作为内核，我们可以使用debian、fedora这样的二进制发行版的基本系统进行扩充及裁减达到我们需要的软件包集合，也可以使用gentoo这样的源代码管理发行版本来制作这样的一个基础系统，你甚至可以使用LFS这样的手册手工打造出一个符合要求的基础系统。
包管理器无关性
这里的包管理器无关性是针对“应用的即插即用”的系统模型所需要的基础系统而言的（包管理器属于组件管理器的一种），我们之所以能够用任何一种方式来建造我们的基础系统，那是因为对于整个系统而言是基础系统被视为一个整体，也就是基础是怎么构造出来的并不要紧，我们关心的是基础系统所包含的部件是否满足我们应用程序的需求，至于用什么包管理器或者什么方式搭出来都是无所谓的。
这里实际上是使用了另一种组件管理器来代替了传统意义上的包管理器。
改变
要制作的系统是的特点是应用“即插即用”，组件管理器实现的是应用系统和基础系统无损对接，不需要将新组件装入基本系统，那么这个基本系统是否可以考虑用只读的方式来存放？
修改的结果是：基础系统所存放的分区以只读的方式挂载（当然你也可以把基本系统以压缩的文件系统方式存放，但需要考虑启动过程中如何挂载），对于类似/etc、/var、/home、/tmp这些需要写入的分区单独处理，像/etc、/home有很多已存在文件的目录，那么可以把其单独成一个分区，在根分区挂载后把该分区挂载到/etc下，对于/tmp这种没有内容的目录采用临时文件系统（内存文件系统）使其可写。那么采用这样的修改后我们需要调整系统启动过程，在适当的时候加载这些分区，从而达到既可以保护基本系统又可以使必要的文件或目录可写。
对于我即将制作的演示系统中基础系统的分析：
我要实现的是“弱依赖性”，我制作的是特定的演示系统，那么演示系统要求能演示就可以，我不必包含太多或者太复杂的组件，只需要少部分就可以了，那么我就采用源代码手工编译的方式就可以了。
那么要满足的需求的基础系统是：内核、核心库、声音驱动库。
四、 支持即插即用的组件管理器
为了实现应用程序的即插即用，系统中必须存在一个“控制装置”，这个“控制装置”就是本系统模型中的“组件管理器”，当然你也可以用其它的名字来称呼，但是它必须能够实现的基本功能是在需要的时候将应用程序与基础系统进行对接，在不需要的时候能够无损基础系统、应用程序及用户数据的情况下解除对接。
分析本系统，本文所要描述即插即用的对接方式可以归结到用户自己去对接的这种方式，属于主动的类型（知情和不知情的情况都可能有），但是它特有的形式是对接方式是由组件管理器在需要的时候自动对接上，在不需要的时候自动断开，实现应用程序的即插即用，但对接还是不对接这最终是由“用户”来决定的。
我们为实现这样的组件管理器，可以采用后台监视程序、特殊的文件系统或者利用特殊的目录结构等方式来达到要求，任何一种方式都是可能实现要求的，在实现的时候可以先采用一种相对简单或者容易实现的方式，今后随着要素的发展逐渐改进方式，或者用其它方式来替换，当然也可以多种方式同时使用。
使用后台监视程序是一种容易实现的方式，我们可以先采用它，通过一个驻留后台的程序监视存储设备的插入动作，将移动存储设备中符合要求的应用程序与基本系统进行对接。
对于我即将制作的演示系统中组件管理器的分析：
我制作的是演示系统，要求不那么高，对接工作打算采用一个循环的bash脚本来实现，udev将辅助完成对U盘插入动作的检测功能。
那么要满足的需求的组件管理器：检测插入操作，把特定目录中的应用程序和基础系统进行对接。
五、 支持即插即用的用户界面
对于要实现的这个“即插既用”的功能恐怕用户界面的设计好坏是至关重要的，用户想要的应用程序由组件管理器对接上了，没一个能反馈已经对接上的信息给用户的功能可是不行的。
那么我们要分析这样的用户界面最重要的是提示应用程序是否被对接上，然后提供让用户去执行这个应用程序的方式，当然还要能够方便的把应用程序从系统里给“断开”，应用被断开不管是用户界面上的操作还是用户直接拔下了存储设备都应该给用户提示。
分析这个要素的基本功能要实现：提示用户、执行程序、“断开”应用。其它的功能可以在要素的成长中逐渐完善。
分析本系统，用户界面的形式也多种多样的，可以是文本、图形或者指示灯，实现的方式通常是程序语言。对于这样一个“即插即用的用户界面”图形方式的表达是最适合的了，一般适合运行的设备也是有图形显示输出的。
需要特别说明的是，对于这样一个系统，用户界面程序可以和组件管理器程序合并在一起，但是我们分析系统的时候将它们分开来单独分析。
对于我即将制作的演示系统中用户界面的分析：
我制作的是演示系统，要求不那么高，只要能表示出提示就可以了，不需要花哨的界面，提示用户应用是否对接了，并能够执行就可以了，所以打算采用bash脚本来实现。
六、 弱依赖关系的开发环境
这应该是开发用户所关心的要素了，对于一个可能很多开发用户不太了解的系统模式就需要提供一个好的开发环境。
分析本系统，开发环境需要提供编译组件，这个系统因为是基于Linux的，那么可以使用Linux的常规开发工具包，如gcc、binutils、gdb等，当然应该将其组合好，不要开发用户为了编译程序还需要花费精力去制作编译组件。
对于如何引导和帮助用户的开发系统开发的文档和规范以及范例是不能少的，开发文档包括：系统的组成，应用程序开发规范、“即插即用”运行机制，“即插即用”的应用程序开发范例。
对于我即将制作的演示系统中开发环境的分析：
我制作的是演示系统，开发环境不需要提供了，如果想要一套打包好的编译组件看来是提供不了了，不过一般的Linux开发环境都是可以的，glibc注意一下，我演示系统用的是2.4，gcc则用的4.1.0。
七、 服务
作为系统的活力源泉——服务，没有它来循环各要素，不能使得系统的内生态得以良性发展。
分析本系统，应该提供的服务包括但不限于：提供包含了基本系统、用户界面、组件管理器的操作系统，系统升级的程序，售后服务软件（用户问题提交、问题结果反馈、信息发布）、用户使用文档，应用用户交流平台，开发用户交流平台、用户获得应用程序的方法、开发环境的获得途径、问题报告平台、信息发布交互平台。
对于我即将制作的演示系统中服务的分析：
我制作的是演示系统，服务上的要求不那么高，提供一个演示系统的使用方法还有本文。
没有服务的系统难以成长，我这个的演示系统成长情况大家也能看出来了。:-)
演示系统下载：
可以查看youbest.blog.cn上的《“应用的即插即用”型操作系统演示系统下载》
说明：
这个演示系统的实现方式多种多样，不局限于演示中使用的脚本方式，演示中的示例软件包也没有考虑多个应用程序存在于一个软件包中的情况，应用程序的参数使用也没有太多的考虑，软件包的配置也很简单潦草，也没有什么容错功能，真实的设计要比这复杂的多，这里仅仅用做演示而已。
结尾
文章结束了，但我对“操作系统构建学”的研究才刚刚开始，文章中有很多概念和观点可能还禁不起推敲，不过没关系我会根据大家的反馈和自己的实践来不断改进它。
在本文下篇中的制作过程分析实际上和上篇中所设计的分析方法实际上是有一定的差距的，我对于理论的理解是：理论对于实践工作是有积极的指导作用的，但是不能在任何时候都无条件的照搬理论，要根据实际情况来进行调整。这不是说理论就没什么用了，不然我也不会花这么多时间和力气来总结了，理论是参考，实践才是检验真理的唯一标准。
孙海勇
2008年6月 |
|
IP卡
狗仔卡
发表于 2008-10-5 16:28:00
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
楼主
发表于 2008-10-5 17:34:26