在上一期的文章中，提到采用Linux为系统软体的种种好处，并分析了自行组装与选择商用套装软体的利弊。然而要如何成功转移专案至Linux，对​​专案负责人来说则是一门重要的课题，在此篇文章中，将分享Linux转移方法学，及其运用的方法。

Linux转移方法学

Linux转移方法学可分成五大阶段：

起始阶段

在启始阶段定义专案的基本要素：最终目标和结果。在这个阶段必须定义Linux转移计画和测试策略，同时也必须考虑Linux所带来的冲击效应及其对软体开发环境产生的最基本改变。举例来说，Linux将改变一些组织的规划与执行，其中包括设计审核与程式码检视等。

若和现在执行的方法相比，组态管理和软体建置问题也可能受到Linux方法的强大影响。发展强硬的组态管理和建置方法，以及建立一个可信赖的软体建置基础设施（build-infrastructure），对于专案而言非常重要。在此阶段最常出现的一项错误就是建置了一些系统，而让工程师几乎不可能和其他开发者或品质测试者建制相同的Linux核心，并在相同的Linux环境内进行开发。有些欠缺经验的Linux开发者为core kernel、kernel patches、中介软体及其他开放原始码程式建立不同的编造系统（build system）。它们都采用人工建置且互不相容，因此可能产生一个无法维持且欠缺生产力的环境。

测试方法将取决于Linux或是Linux供应商和开放原始码社群提供的可用测试资源。 LTP（Linux Test Project）、LM Bench以及其他诸如此类的专案，将值得这个启始阶段评估采纳。

需求阶段

软体需求问题仍旧是关键性的课题，即使专案将不能显著改变系统功能性亦然，因为必须将完整系统的需求向下推至Linux系统的基本架构单元。这些需求涵盖从软体基础阶层（包括boot loader、Linux BSP、root档案系统、以及应用程式所需的kernel mode drivers等）到选择性的中介软体阶层，以及最后的应用程式。在一个转移计画中，由于是移植自一个既有的系统，因此在系统功能需求上所需投注的时间较少，而在有关系统属性例如footprint、bootup time和效能等方面则需要投注较多的时间。如果转移并未涉及为系统增加新功能，则更是如此。再者，品质需求可能需要涉及Linux架构上的决策，例如将应用程式分割成多重程序或程序内的多重执行绪。

设计阶段

软体设计阶段需要建立有关软体建置与设计方法的文件，而这涉及一些关键的决策。例如必须决定如何将RTOS-based应用程式转换成一个Linux应用程式，这项决策必须仰赖对于这二种作业系统基底架构（二者可能差异相当大）的知识。设计问题会对包括软体基础（software foundation）、中介软体和应用程式的所有阶层产生潜在的影响。一个高度成功的策略是把中介软体层当成应用程式的主要抽象点（abstraction point），这种方法可以独立以此层为主的变更，因此可以保留对于应用程式码的大部分投资。

在这个阶段，需要计画和设计一个整合系统工作。可以运用既有系统的测试资产，包括测试平台、测试设备、测试程式以及完整系统测试。如果没有这些既有资产，则需要一一建立。基本上，每一阶层的测试、单元测试和元件测试，在Linux上的外观和行为都可能与先前的设备作业系统不同。

程式码和单元测试阶段

在编码阶段，必须有一个稳定且完整的软体开发环境。开发人员将在这阶段频繁使用组态管理环境和除错环境，以及软体建置基础设施和测试资产。发展的编码标准，可能已因为Linux而不同于先前的专案，而它们将在本阶段被频繁的使用。

测试方法经常被忽略，很多人直到专案后期才寻求解决，但事实上这必须从一开始即进行规划。选择Linux有助于运用Linux商用套装软体供应商和（或）开放原始码社群，以改善测试资产和测试科技。自动化测试可以改善生产力和上市时程，但必须从一开始即详细规划和分析才能达到这些目标。系统测试应运用既有的产品基础设施，而单元测试（例如软体基础测试）则会不同于既有的系统。

测试与转移阶段

当最终系统进行测试转移时，将发现整合测试是在测试资源和测试设备等方面的一项重大投资。为了减少测试成本，则可以运用之前针对原始系统投资的测试套件和基础设施，为Linux转移专案提供正确的系统测试平台。一个Linux-based系统将会影响建置系统、品质系统、版本管理以及开发环境里的所有单元。因此，必须审慎做好最终测试与整合的规划工作。最终测试永远是一个关键性的程序，同时也是系统完成转移、正式推出前必经的步骤。

转移方法学运用

运用转移专案方法学的架构，协助解决转换过程中可能出现的一些技术问题。这项运用可以划分为方法学内的三个活动领域，包括软体基础、中介软体和应用程式。其中，软体基础可能不需要太多的支援。既有的中介软体和使用的third-party中介软体，是这项运用的关键重心，而应用程式码则是最终考量的领域。

软体基础

软体基础包括一个Linux bootloader（开机载入程式）和一个Linux硬体平台支援套件（Board Support Package;；BSP）。有关这些单元的转换协助工具已在其他文献详尽的探讨，不过必须注意既有系统的boot time、footprint、自我测试和软体升级需求，也要在转移后的系统上获得满足。拥有一个功能性的bootloader是一回事，而拥有一个符合系统特定需求的bootloader则是另一回事。许多设备可以利用商用Linux厂商提供的Linux BSP，而其他则需要一个客制化BSP。客制化BSP可以从一个「近亲」着手，意即采纳一个商用BSP或开放原始码社群供应的BSP。大多数转换专案并未运用既有的设备BSP，即使是在转移专案内采用了相同的硬体亦然。

另一方面，许多设备可以采纳既有的设备驱动程式码，例如device net和memory maps。但如果既有的驱动程式码无法运用，则开放原始码社群或许可以提供一个有用的来源。不论是转换既有的驱动程式，或者从开放原始码社群亦或向Linux厂商寻求新的驱动程式，这个阶段的挑战在于一个关键问题：这些驱动程式能否符合设备需求？

若能在这个专案阶段开始实施效能微调，将可以带来许多效益。效能微调问题可能会在初期软体基础阶层出现。最简单的解决方案就是在bootloader、BSP或设备驱动程式阶层（与中介软体和档案应用程式隔离）排除初期的效能问题。若将所有效能微调延误到最终的整合阶段，将会对最终专案阶段形成过大的压力，让问题孤立更加困难许多。

中介软体和应用软体

一并为中介软体和应用软体编码或许是最简单的方式。许多应用程式仰赖提供应用程式服务的中介软体阶层，然后将基底的作业系统予以抽象化。事实上，这种架构有助于转移专案为应用程式完成支援阶层。这个阶层应接受测试并独立于完整应用程式之外，其用意同样是为了协助故障阻隔（fault isolation），并仰赖那应已完成的软体基础测试。

在这个阶段，要确认厂商是否提供Linux支援。厂商提供的Linux支援可以显著降低Linux转移挑战。如果中介软体厂商并未提供Linux支援的版本，或者是自行设计中介软体，则必须确认需要为中介软体架构进行那些变更。

中介软体转换策略必须以既有或者新增加的中介软体为基础。当在进行中介软体和应用软体转换时，可以选择以原始的设备作业系统作为模型、进行模拟或予以虚拟化。中介软体可以使用原生Linux架构或者所设计的一个移植阶层（porting layer）。请注意，中介软体的任何变更都将影响应用程式。

一旦完成Linux转移和应用程式移植后，紧接着就要进行整体系统的整合，而最终效能尺度将在这个阶段评定。如果已正确完成软体基础和中介软体层的工作，那么在整体系统整合上可能遭遇的意外将大幅减少。再者，如果较低层的工作已确实达成，则应用程式码本身的变更将可以妥善的孤立且更容易完成。

整合测试

Linux在测试方面提供一些有用的资源，例如：

整合测试需要针对每一阶层以及最终的系统阶层进行规划和执行。

软体基础测试

建立一个强固的软体基础，包括可供做为更高层级测试之基础的品质与stress测试，将能带来很多效益。建立一个这样的基础，需要确立可供向下支援的明确需求，例如启动时间和设备驱动程式效能，以及完善的品质stress测试。在中介软体内执行独立于应用程式码之外的设备驱动程式和stress测试，有助于您专案的发展，它产生一个更好的软体基础，能在错误孤立层提供协助。

中介软体测试

中介软体测试建立在软体基础测试之上。可以利用third-party厂商提供的测试组或先前专案使用的测试组，建立中介软体层（有别于应用软体）信心。中介软体测试可能需要编写一个测试应用程式，来对中介软体进行先前未曾有过的测试。然而，一如软体基础测试，中介软体测试同样对于故障隔离有很大的帮助。

应用程式测试

应用程式测试是最终的系统测试阶段，亦即产品推出前的最终确认。或许可以在产品正式推出前利用模拟环境，但是这个应用程式测试阶段则可以协助进一步强化已建立的测试基础。一个定义完善的系统架构、向下支援至较低阶层的需求、孤立于应用程式和移植之外的变更、以及一组测试完善的程式码都将协助顺利完成转移。

其他挑战

关于转移上的其他问题，虽然属于比较一般性的问题（而非Linux特定化的问题），但如果忽略则可能导致最后的失败，就如同如果不测试设备驱动程式的话就会失败一样。

变更管理

转移到一个开放原始码方案的结果，将为开发组织带来深远的改变。原先负责将新科技整合到专属性作业系统的工程师们，现在变成需要负责测试和验证Linux，而非从事作业系统的开发。支援人员现在需要管理来自商用支援中心的问题回应，而非负责旧作业系统的修补编码工作。

程序

如果开发团队首度投入开放原始码软体世界，那么开发、发行和支援程序都会产生改变。如果未选择一个Linux商用套装软体，那么如何决定从何处下载程式和修补软体？亦或是选择成为一个自己动手作的Linux消费者，那么就需要管理自己的作业系统，让自己变成从事作业系统工作的人。

教育训练

工程师是否具备Linux经验，如果没有的话，该如何尽可能加速其Linux能力？ Linux商用套装软体供应商可能也提供教育训练服务，这是让内部员工快速上手的成本效益方式。课堂教学、现场学习、线上学习和电脑辅助训练等，都是获得Linux知识的途径。另一种方式是聘请顾问师协助转移并带领内部员工学习。这非仅可以吸收来自业界和科技专家的高品质经验，同时也能够提升内部员工的竞争力。

寻求协助的准则

现在，回到专案的起点。一旦应用程式完成转移，接着就要评量成果，产品上市时程是否更快？是否因为可以投注更多资源在其上而功能更丰富，或者可以更快达到营收成长呢？是否降低成本而不会影响生产力或功能性？为确保成功，可以寻求协助进行Linux转移。那么，该如何选择正确的服务伙伴呢？

最后，服务伙伴应能提供人才、程序和科技等整体资源，协助达成Linux转移目标。

结语

虽然Linux转移对于任何不熟悉该科技的人而言或许会感到畏惧，但是只要能建立一个妥善且业经测试的转移程序，就能奠立成功的基础。

延 伸 阅 读

ODBC Driver Manager在Linux中却一直没有相同的设定；现在Linux也有了类似的unixODBC了，unixODBC的组织尝试在Linux底下，建立类似ODBC Driver Manager的机制。此一机制与ODBC Driver Manager的功能相仿，提供Runtime的动态变换功能，让AP可以透过ODBC Driver Manager，动态地载入不同的资料库Driver。相关介绍请见「如何在Linux上安装unixODBC + DBMaker」一文。 现有的电源管理方案分别来自于PC和笔记型电脑领域：一个是传统的高级电源管理（APM）方案，它目前仍然使用在许多基于Linux的可携设备中，另一个是高级配置和电源介面（ ACPI）方案，它是英特尔、东芝和其他一些公司支援的现行标准。 ACPI的系统是人们的首选，但它强烈依赖于流行的x86/IA-32 BIOS架构。 你可在「用于可携式装置动态电源管理的嵌入式Linux技术 」一文中得到进一步的介绍。 在Alpha/AXP平台上引导Linux通常有两种方法，一种是由MILO及其他类似的引导程式引导，另一种是由Firmware直接引导。 MILO功能与i386平台的LILO相近，但内置有基本的磁片驱动程式（如IDE、SCSI等），以及常见的系统驱动程式（如ext2，iso9660等）。在「Linux启动过程综述 」一文为你做了相关的评析。

市场动态

Linux将在商业级移动设备中扮演更重要的角色，调研公司Mobile Ecosystem执行总监Mark Lowenstein预测商业化将左右手机的特性，他表示。调研公司预测，Linux在移动设备的市场份额将由去年的11.3％增加到2009年的17％。相关介绍请见「产业观察：商业应用与Linux主导手机下一波热潮」一文。 原先让业者乐观以待的Linux台湾计画，预算从原先的共识三年6.3亿元，大幅缩减为十八个月9900万元，官员表示，因去年科技预算统删，造成相关计画预算也泡汤，现有预算则来自于科学技术发展基金，基于救急不救穷的原则，预算金额无法提高。你可在「Linux计画严重缩水 业界期盼速谋补救」一文中得到进一步的介绍。 名为Project LiMux的慕尼黑市政府Linux转移计画，预计在2006年以前将一万四千部桌上型电脑的作业系统从Windows转移到Linux，随后包括英国、挪威、奥地利等地都出现跟进。而开放源码风险管理公司发表一份Linux核心可能侵犯了283项专利的报告后，慕尼黑市政府暂停了Project LiMux计画。在「德国慕尼黑市政府暂停Linux转移计画」一文为你做了相关的评析。