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

由于現(xiàn)在可以在目標(biāo)硬件上運行各種經(jīng)過驗證的開源軟件，平臺工程師的典型日常任務(wù)轉(zhuǎn)而專注于現(xiàn)有開源軟件的配置、定制和集成，而不是設(shè)計和開發(fā)從零開始的軟件。鑒于這種轉(zhuǎn)變，讓我們回顧一下在決定是否基于開源軟件構(gòu)建產(chǎn)品時要考慮的以下四個主要產(chǎn)品生命周期工作流程挑戰(zhàn)：

為應(yīng)用程序團隊創(chuàng)建定制的軟件開發(fā)工具包 （SDK）；

跟蹤開源軟件更新；

從源代碼重建平臺；和

管理與各種許可證相關(guān)的開源軟件義務(wù)。

創(chuàng)建自定義 SDK

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

工程師的工作做得如何？

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

他們?nèi)绾螌?SDK 分發(fā)給其他團隊成員？

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

創(chuàng)建自定義 SDK 基本上歸結(jié)為選擇應(yīng)用程序開發(fā)人員應(yīng)該使用的一組庫和 API，然后確保它們以受版本控制的方式內(nèi)置到應(yīng)用程序開發(fā)工具鏈中。如果應(yīng)用程序?qū)⒗脛討B(tài)鏈接，那么這也意味著確保為開發(fā)人員的桌面以及運行時目標(biāo)映像構(gòu)建一致的版本。以易于安裝的格式提供 SDK 有助于確保所有應(yīng)用程序開發(fā)人員的一致性。

跟蹤開源更新

團隊中誰負(fù)責(zé)跟蹤對公司產(chǎn)品內(nèi)運行的開源軟件所做的更新？他們?nèi)绾巫龅竭@一點，多久一次？他們在尋找什么樣的更新？安全補丁和錯誤修復(fù)是否與新功能發(fā)布一樣受到關(guān)注？他們?nèi)绾闻c團隊其他成員一致地分享這些更新？

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

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

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

從源代碼重建平臺

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

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

管理開源軟件義務(wù)

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

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

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

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

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

確保開發(fā)團隊了解并遵守與這些開源許可證相關(guān)的義務(wù)需要時間和精力。在嘗試達(dá)到激進(jìn)的產(chǎn)品開發(fā)里程碑時，可以幫助識別和跟蹤適用的基礎(chǔ)許可并實現(xiàn)許可義務(wù)的工具可以證明是非常有價值的。

從一開始就考慮工作流程

開源的使用給整個嵌入式產(chǎn)品開發(fā)生命周期帶來了一系列新的工作流程挑戰(zhàn)。通過在新產(chǎn)品開發(fā)開始時考慮這些挑戰(zhàn)，通過指定適當(dāng)?shù)墓こ處焷碡?fù)責(zé)各種問題，并通過為工程師配備適當(dāng)?shù)墓ぞ撸芾砣藛T可以通過最大限度地減少對進(jìn)度的意外影響來確保項目更成功。

審核編輯：郭婷