在上一期的文章中，提到採用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轉移計畫」一文為你做了相關的評析。