隨著預算的減少、產品生命周期的縮短以及更多的功能被集成到電子設備中，開發人員感受到了交付高級軟件的壓力。雖然 Linux 和開源通常是嵌入式開發的正確選擇，但它們不能發揮神奇的作用。一些成本仍然與選擇開源開發工具相關。在決定使用哪些工具時，開發人員必須考慮他們是否將時間花在真正具有創新性和差異化的東西上，還是花在諸如集成和支持之類的繁忙工作上。

工具選擇可以幫助或阻礙開發人員獲得項目控制權的努力。真正有價值的工具的試金石是它們是否可以幫助開發人員在產品的短暫生命周期內啟用正確的功能。

遭受這種失控的嵌入式 Linux 開發的一個領域是構建 Linux 所依賴的通常復雜的文件系統的過程。平臺開發人員需要集成和安裝數十個甚至數百個獨立的軟件組件，但手動創建目標文件系統既耗時、困難又復雜。如果沒有合適的工具，這個過程很容易出錯。這些時間和精力可以更好地用于開發使產品與競爭對手區分開來的功能。Linux 文件系統配置是最困難且在某種意義上回報最少的活動。

傳統Linux開發

Linux 的第一個版本是在目標位于主機本身或類似機器上的環境中開發的。正因為如此，伴隨的工具傳統上是針對主機開發環境量身定制的。從根本上說，開發人員更容易為與他們正在開發的機器類似的機器進行開發。隨著目標環境離宿主環境越來越遠，開發者面臨的挑戰也越來越大。

為主機或類似環境進行開發不需要太多額外的工作。事實上，一些嵌入式系統與 PC 非常相似，開發人員可以運行他們選擇的實際 Linux 發行版，例如 SuSe 或 Fedora。但是，針對當今市場上的一種不同處理器架構進行開發可能是一項挑戰。

嵌入式Linux開發和交叉開發

當資源受到限制并且目標處理器正在運行許多可用的非 x86 處理器之一時，環境會變得更加復雜。在這種環境中，在具有許多資源的主機上進行開發，然后交叉編譯為特定處理器架構開發二進制文件會更有效率。

由于其模塊化設計，Linux 可以在小型設備上高效運行。開發人員可以選擇他們想要實現的功能并刪除他們不需要的功能。完成此任務并微調特定設備的功能和用戶界面需要真正的技巧。

但僅僅因為它是模塊化的，并不意味著有一條明確的成功之路。開發人員必須考慮兩種方法：遵循基于包的安裝，利用大多數可用的 Linux 發行版，或者將包集成到構建系統環境中。構建系統的一個問題是它與 Linux 的分發方式不一致，通常是像 .deb 或 .rpm 這樣的包。另一個挑戰是任何特定構建系統所需的學習曲線。以下討論將介紹包管理器并解釋它們如何幫助或損害開發人員構建嵌入式 Linux 文件系統的能力。

選擇嵌入式 Linux 文件系統管理器

Debian GNU/Linux 發行版的創始人 Ian Murdock 將包管理描述為“Linux 為行業帶來的最大進步。”他認為包管理模糊了操作系統 （OS） 和應用程序之間的界限，使其“更容易”推動新的創新，“??進入市場”，“??和發展操作系統。”，?ù

可用于構建嵌入式 Linux 文件系統的工具在跨平臺和資源受限的環境中變得更加有用。開發人員在選擇特定工具或集成開發環境 （IDE） 之前提出幾個問題非常重要。考慮一下：您從哪里獲得 Linux 源代碼，以及它是如何打包交付的？您將文件系統用于什么目的，如何針對特定目標對其進行優化？開發人員選擇的軟件包安裝程序可以在優化的文件系統和嵌入式設備的糟糕借口之間產生差異。

管理嵌入式 Linux 文件系統的常用方法是使用 RPM 或 dpkg 之類的包管理器來安裝和刪除非 root 目錄，fakeroot 用于偷偷摸摸地執行不需要 root 權限的 chroot，或者使用虛擬目標進行開發，例如Linux QEMU 處理器仿真器或 Virtutech，??s Simics 虛擬平臺。這些不同的選項中的每一個都有優點和缺點，可以通過替代解決方案來彌補：平臺圖像構建器。

包管理器

文件系統管理的衛冕冠軍是 RPM 包管理器。RPM 很有用，因為它是標準的并且在大多數 Linux 系統上都可用。與其他同類產品一樣，RPM 具有安裝到非系統根目錄的內置功能，這是有利的，因為聰明的開發人員不希望意外破壞其主機文件系統的能力。但是 RPM 并沒有解決包依賴問題；它只是確定是否滿足依賴關系。它要求開發人員已經知道依賴關系，因此不會去檢查各種包以確定需要解析哪些包來構建文件系統。

要解決依賴關系，開發人員必須添加另一個工具，例如 Yellowdog Updater （yum） 或 Advanced Packaging Tool （apt）。作為一個 C++ 函數庫，創建 apt 是為了在升級期間處理依賴關系和處理配置文件時有效地安裝包。但是，apt 和 yum 僅限于命令行。如果開發人員不熟悉 Linux 或這些工具，他們可能會面臨相對陡峭的學習曲線。此外，所有信息都是文本的，并且相對于圖形文件系統管理器通常難以導航。

偽裝根

Linux 可以適當地設置權限，以保護系統免受與修改或刪除文件相關的惡意意圖、無知或健忘。Linux 有一個包含所有子目錄的基本根目錄。這個基本根，通常稱為 ??ú/??ù（發音為斜線），受到 Linux 系統用戶的保護。管理員限制對“?ú/”?ù 的訪問，并在其下為每個用戶提供可修改的主子目錄。這使用戶能夠訪問系統并以適當的權限和能力完成他們的任務。

但是，某些文件系統創建操作需要 root 權限。如果沒有 root 權限，開發人員無法創建其他用戶擁有的文件、創建設備節點或提交更改 root 操作。這些限制限制了配置文件系統的能力。

一種選擇是使用像 fakeroot 這樣的工具，它可以在用戶主機系統的目錄中創建一個虛擬的“?ú/”文件系統樹。它通過重新定義主機系統庫中的標準函數來提供一個假的“?ú/”?ù 環境。通過這種方式，它更改了引用文件的實用程序并捕獲有關文件的特權信息，而無需 root 特權來創建它們。此外，它可以與標準實用程序一起使用，而無需特殊工具。與 RPM 一樣，fakeroot 不解決依賴關系，將這項艱巨的任務留給了開發人員。

在這里，RPM 和 fakeroot 都面臨一個額外的挑戰：開發人員可能希望在目標目錄中執行代碼，如果該代碼用于與主機不同的架構，它根本無法運行。

虛擬開發

構建文件系統的第三種替代方法是使用虛擬環境，如 QEMU、Simics 或 VMware Workstation。這解決了包管理器和 fakeroot 工具都面臨的挑戰，即無法在與目標架構不同的主機上運行代碼。虛擬環境還提供了使用主機上所有可用資源（例如內存、存儲和快速處理器）為虛擬目標進行開發的能力，享受 PC 上自托管開發的許多優勢。

使用虛擬環境通常比在目標本身上進行開發要快，但它會增加復雜性，相對于交叉開發降低處理器能力。

平臺鏡像生成器

如本文開頭所述，平臺開發人員需要集成和安裝數十個（如果不是數百個）單獨的軟件組件，但手動創建目標文件系統既耗時、困難又復雜。創建文件系統后，必須將其轉換為目標圖像（參見側欄）。更高級的工具可以簡化組裝、調整和創建文件系統映像的任務。

平臺映像生成器通過提供系統的可視化地圖來實現這一點，用于選擇 Linux 目標包、集成自定義包和內核、動態確定文件系統大小、自動解決依賴關系和沖突，以及生成多種標準格式的文件系統。

平臺圖像構建器對于從最終圖像中修剪組件很有用，無論它們是單個文件還是整個層次結構（例如，文檔和示例配置文件）。能夠將包明顯地分類為文檔、字體、圖形或解釋器等組，可以讓開發人員快速訪問和更快地消除不必要的包（參見圖 1）。

圖1

此功能還使用戶能夠通過樹層次結構對文件和目錄進行下鉆和排序。要刪除文件，只需取消選中相鄰的框（圖 2）。除了刪除單個文件外，開發人員還可以選擇將整個所需的支持包標記為“?úphantom”。?ù 這樣的包是構建其他包所必需的，但不是最終構建所必需的，因此在運行時不包括在內。

圖 2

在設置平臺映像項目 （.pib） 時，開發人員可以包含和集成自定義包和內核。這種靈活性提供了競爭差異化和控制嵌入式開發人員在如此快節奏的市場中的需求。

平臺映像生成器提供了許多影響映像文件大小的選項。它通過以下方式做到這一點：

優化庫占用空間并減小一些共享庫的大小

預鏈接可執行文件，加快啟動速度

從最終的二進制文件中刪除調試符號，使它們更小更快

這些措施不僅是為了減小圖像的大小，而且是為了提高性能。

平臺映像生成器使用 RPM 包中包含的依賴信息來根據需要自動包含支持包（圖 3）。這與 Linux 通常的分發方式是一致的，并且消除了手動計算依賴項的平凡任務。但是，在進行包選擇時，可以選擇相互沖突的包。由于這會導致錯誤并阻止項目成功構建，因此開發人員必須在創建映像之前解決沖突。平臺映像生成器通過將所有沖突標記和列出為錯誤來提供幫助，從而可以輕松查看和更改它們，直到所有沖突都被消除。

圖 3

最后，借助平臺鏡像生成器等文件系統管理工具，平臺開發人員可以生成常用的文件格式，包括 ext2、JFFS2、cpio、CRAMFS 和 ext3。根據格式，可以使用不同的選項來配置映像和設置掛載點。

與前面提到的為嵌入式 Linux 開發創建和管理文件系統的方法相比，平臺映像生成器具有圖形用戶界面，不需要模擬環境，因此不會使用與虛擬機相關的資源。平臺映像生成器將文件系統轉換為映像，沒有復雜性和較慢的處理能力，為開發人員提供嵌入式 Linux 交叉開發項目所需的生產力。

工具試金石

嵌入式 Linux 開發人員可以使用平臺映像生成器等工具獲得對構建復雜文件系統的更多控制，這使得組裝、調整和創建文件系統映像更容易完成。這使開發人員能夠花時間開發使產品與競爭對手區分開來的功能。請記住，真正有價值的工具的試金石是它們是否可以幫助開發人員在產品的短生命周期內啟用更多正確的功能。

作者：Troy Kitch，Joe Green

審核編輯：郭婷