在嵌入式 Linux 開發的早期（大約 Y2K），其中很大一部分工作是將開源代碼移植到目標硬件平臺上運行。除非工程師在 Intel x86 板上運行代碼，否則開發板支持包 （BSP） 并交叉編譯開源中間件以在硬件上運行并非易事。從那以后的幾年里，越來越多的硬件公司發現，提供免費的 Linux BSP 對于確保其硬件在嵌入式應用程序中的廣泛采用是必要的。在早期，通過控制臺端口到達 Linux shell 提示符可能需要數周或數月的時間，而現在應該只需要幾個小時。

由于現在可以在目標硬件上運行各種經過驗證的開源軟件，平臺工程師的典型日常任務轉而專注于現有開源軟件的配置、定制和集成，而不是設計和開發從零開始的軟件。鑒于這種轉變，讓我們回顧一下在決定是否基于開源軟件構建產品時要考慮的以下四個主要產品生命周期工作流程挑戰：

為應用程序團隊創建定制的軟件開發工具包 （SDK）；

跟蹤開源軟件更新；

從源代碼重建平臺；和

管理與各種許可證相關的開源軟件義務。

創建自定義 SDK

隨著工程師越來越多地將嵌入式 Linux 視為可以在其公司的許多產品中重復使用的通用軟件平臺，創建定制的 SDK 變得比創建 BSP 更重要。應用程序開發人員喜歡 Android 和 iOS，因為 Google 和 Apple 在為他們的手機和平板電腦平臺構建和維護自定義但功能強大且易于使用的 SDK 方面做得很好。誰在為開發工程師為您的硬件平臺構建應用程序奠定基礎？如果一家公司擁有一名正式負責為應用程序開發團隊創建和維護自定義 SDK 的工程師，則該公司處于領先地位。如果公司有人負責這項正在進行的任務，經理應該能夠回答以下問題：

工程師的工作做得如何？

他們花了多少時間做這件事？

他們如何將 SDK 分發給其他團隊成員？

如果這個人（或平臺團隊中的關鍵人物）離開了公司，是否有人可以介入并有效地接管這個角色？

創建自定義 SDK 基本上歸結為選擇應用程序開發人員應該使用的一組庫和 API，然后確保它們以受版本控制的方式內置到應用程序開發工具鏈中。如果應用程序將利用動態鏈接，那么這也意味著確保為開發人員的桌面以及運行時目標映像構建一致的版本。以易于安裝的格式提供 SDK 有助于確保所有應用程序開發人員的一致性。

跟蹤開源更新

團隊中誰負責跟蹤對公司產品內運行的開源軟件所做的更新？他們如何做到這一點，多久一次？他們在尋找什么樣的更新？安全補丁和錯誤修復是否與新功能發布一樣受到關注？他們如何與團隊其他成員一致地分享這些更新？

我們與一位客戶合作，通過讓三名工程師每周一天在午餐時間工作來解決這個特定問題。為了確保他們了解他們在公司產品中使用的開源軟件包的所有最新更新，三位工程師將筆記本電腦顯示器投影到會議室的屏幕上，并瀏覽各種網站、變更日志、GIT 樹、郵件列表存檔和下載站點。雖然這不一定是最有效的方法，但它確實說明了保持最新狀態的積極努力 - 并且還說明了這樣做所需的工程時間投資。

自動化可以在這方面有所幫助。訂閱 Timesys LinuxLink 服務 （linuxlink.timesys.com）、CERT 郵件列表 （forms.us-cert.gov/maillists） 或 Freecode（原freshmeat.org）等網站，（見圖 1），可以放置一些結構通過將相關的、經過過濾的開源更新直接流式傳輸到 Web 瀏覽器或電子郵件收件箱中，圍繞這項工作并節省時間。

圖 1：當開源軟件包的更新版本可供下載時，LinuxLink 更新引擎會通知平臺工程師。

從源代碼重建平臺

曾經嘗試從 RPM 或 Debian 源代碼重建桌面發行版嗎？祝你好運。雖然分發人員確實提供了源代碼（畢竟它是開源的），但從源代碼重建絕對不是他們通常支持的用例。在大多數情況下，從源代碼包重建后，生成的系統不會被視為相同的發行版，因此供應商不太可能支持。

雖然這對于企業或桌面 Linux 環境來說可能是可以接受的，但對于嵌入式產品公司來說卻是不可接受的。典型的嵌入式產品在該領域使用多年，出貨后往往需要維護和更新。保留嵌入式產品的每個交付版本中包含的所有軟件的詳細清單以及用于構建它的工具和腳本是至關重要的。當今許多現代 Linux 構建引擎都提供了此功能，因此請務必選擇一個提供此功能的引擎。

管理開源軟件義務

與大多數基于開源平臺構建的典型嵌入式產品一樣，開發團隊可能必須跟蹤許多不同的開源許可證所產生的義務，而不僅僅是單個許可證。作為一個例子，我們提供了“小尺寸起點”，它們是預先構建的嵌入式 Linux 映像，通常只有幾兆字節大小，可以簡化嵌入式 Linux 的快速啟動和運行。如圖 2 所示，一個占用空間小的起點可能只包括七個開源包，但這七個包實際上屬于四個不同的開源許可證。

圖 2： Timesys 小尺寸起點圖像中的開源軟件包和相關許可證

作為另一個例子，考慮一下索尼提供的相對簡單的無線數碼相框 （ www.docs.sony.com/release/VGFCP1_qs.pdf ）。如圖 3 所示，該產品基于 20 個不同的開源軟件包 （ www.sony.net/Products/Linux/VAIO/VGF-CP1.html ），同樣涵蓋各種不同的開源許可證。

圖 3：索尼無線數碼相框中包含的開源包

在嵌入式產品設計中使用每種類型的開源許可證對將這種軟件整合到他們的產品中的開發團隊施加了一組獨特的義務。正因為如此，一些公司維護了一個開源許可證列表，供其開發人員使用。其他公司走得更遠，明確列出了每個開源軟件包的哪個特定版本已被批準可能并入公司的產品中。

確保開發團隊了解并遵守與這些開源許可證相關的義務需要時間和精力。在嘗試達到激進的產品開發里程碑時，可以幫助識別和跟蹤適用的基礎許可并實現許可義務的工具可以證明是非常有價值的。

從一開始就考慮工作流程

開源的使用給整個嵌入式產品開發生命周期帶來了一系列新的工作流程挑戰。通過在新產品開發開始時考慮這些挑戰，通過指定適當的工程師來負責各種問題，并通過為工程師配備適當的工具，管理人員可以通過最大限度地減少對進度的意外影響來確保項目更成功。

審核編輯：郭婷