在當今由物聯(lián)網(wǎng)（IOT）驅(qū)動的互聯(lián)嵌入式設(shè)備市場中，開發(fā)中的大部分設(shè)備都是以某種形式的Linux為基礎(chǔ)的。具有現(xiàn)成Linux發(fā)行版的低成本電路板的普及應(yīng)用是這方面的關(guān)鍵驅(qū)動因素。而獲取硬件，構(gòu)建自定義代碼，將設(shè)備連接到其他硬件外圍設(shè)備和互聯(lián)網(wǎng)中，以及使用商業(yè)云提供商進行設(shè)備管理從未如此簡單。開發(fā)人員或開發(fā)團隊可以快速構(gòu)建新應(yīng)用程序的原型，并將設(shè)備提供給潛在用戶。這是一件好事，將產(chǎn)生許多有趣的新應(yīng)用，但也產(chǎn)生了許多不良的應(yīng)用。

在規(guī)劃超出原型設(shè)計階段的系統(tǒng)設(shè)計時，事情變得更加復(fù)雜。本文主要對開發(fā)和維護基本操作系統(tǒng)（OS）映像的機制進行闡述。有許多工具可以幫助解決這個問題，但在此不會討論各種工具。這里感興趣的是維持和增強這種形象的基本模式，以及它將如何使人們的生活變得更好或更糟。

生成這些映像有兩種主要模型：

Centralized Golden Master

分布式構(gòu)建系統(tǒng)

這些類別反映了源代碼管理（SCM）系統(tǒng)的驅(qū)動模型，在討論操作系統(tǒng)映像時，許多關(guān)于集中式和分布式的論點都是適用的。

Centralized Golden Master

業(yè)余愛好者和制造商項目主要使用Centralized Golden Master方法來創(chuàng)建和維護應(yīng)用程序映像。這一事實使該模型具有速度和熟悉度的優(yōu)勢，允許開發(fā)人員快速設(shè)置這樣的系統(tǒng)并使其運行。這一速度來自于許多設(shè)備制造商為其現(xiàn)成的硬件提供固定映像的事實。例如，來自BeagleBone和Raspberry Pi等系列的主板提供即用型操作系統(tǒng)映像和閃存。依靠這些映像意味著只需點擊幾下鼠標即可啟動并運行系統(tǒng)。這些映像通?；谠S多設(shè)備開發(fā)人員已經(jīng)使用的桌面發(fā)行版，例如Debian。多年使用Linux可以直接轉(zhuǎn)移到嵌入式設(shè)計，包括包裝實用程序基本保持相同的事實，而且對于設(shè)計人員來說，獲得他們需要的額外軟件包很簡單。

這種方法有一些缺點。首先，Centralized Golden Master的映像通常是一個瓶頸，導(dǎo)致原型設(shè)計階段后開發(fā)人員的工作效率下降，因為每個人都必須等待輪到他們訪問***映像并進行更改。在供應(yīng)鏈管理（SCM）領(lǐng)域，這種做法相當于具有單獨文件鎖定的集中式系統(tǒng)。只有具有鎖定的開發(fā)人員才能處理任何給定的文件。

這種方法的第二個缺點是映像再現(xiàn)性。通常通過人工登錄目標系統(tǒng)，使用本機包管理器安裝包、配置應(yīng)用程序和點文件，然后就地修改系統(tǒng)配置文件來管理。完成此過程后，將使用dd命令的實用程序或等效工具對磁盤進行映像，然后進行分發(fā)。

同樣，這種方法會造成潛在問題。例如，基于網(wǎng)絡(luò)的軟件包源可能不再存在，并且供應(yīng)商映像提供的基礎(chǔ)軟件可能會更改。腳本可以幫助緩解這些問題。但是，當對配置文件格式或供應(yīng)商的基本軟件包進行更改時，這些腳本往往很脆弱并且會中斷。

這種開發(fā)模式產(chǎn)生的***一個問題是依賴第三方。如果硬件供應(yīng)商的映像更改不適合企業(yè)的設(shè)計，則可能需要投入大量時間進行調(diào)整。

分布式構(gòu)建系統(tǒng)

這種為應(yīng)用程序創(chuàng)建和維護映像的方法依賴于與目標硬件分離的目標映像的生成。這里的開發(fā)人員工作流程類似于使用供應(yīng)鏈管理（SCM）系統(tǒng)的標準軟件開發(fā);映像可以通過工具完全構(gòu)建，每個開發(fā)人員都可以獨立工作。通過編輯元數(shù)據(jù)文件（腳本、配方、配置文件等）對系統(tǒng)進行更改，然后重新運行工具以生成更新的映像。然后使用供應(yīng)鏈管理（SCM）系統(tǒng)管理這些元數(shù)據(jù)文件。各個開發(fā)人員可以將***的更改合并到他們的工作副本中，以生成他們的開發(fā)映像。在這種情況下，開發(fā)人員可以避免相關(guān)的瓶頸。

然后，構(gòu)建系統(tǒng)使用標準供應(yīng)鏈管理（SCM）技術(shù)生成發(fā)布映像，以從所有開發(fā)人員處獲取更改。

以這種方式工作可以增加開發(fā)團隊的規(guī)模，而不會降低開發(fā)人員的工作效率。所有工程師都可以獨立工作。此外，這種設(shè)置可確保企業(yè)的構(gòu)建可以重現(xiàn)。使用標準供應(yīng)鏈管理（SCM）工作流可以確保在未來的時間重新生成特定的構(gòu)建，從而允許長期維護，即使上游提供程序不再可用。與使用分布式供應(yīng)鏈管理（SCM）工具類似，還需要有其他策略來實現(xiàn)可重現(xiàn)的候選映像。各個開發(fā)人員擁有自己的源代碼副本，并且可以構(gòu)建自己的測試映像，但是為了正確的發(fā)布工作，開發(fā)團隊需要建立合并和分支標準，并確保所有針對發(fā)布的更改最終合并到明確定義中。許多上游項目已經(jīng)為這種發(fā)布策略定義了明確的流程（例如，使用* -stable和* -next分支）。

這種方法的主要缺點是缺乏熟悉度。例如，向映像添加包通常需要創(chuàng)建某種配方，然后更新定義，以便包二進制文件包含在映像中。這與登錄到正在運行的系統(tǒng)時運行apt非常不同。這些系統(tǒng)的學(xué)習(xí)曲線可能令人生畏，但結(jié)果更具可預(yù)測性和可擴展性，在考慮大規(guī)模生產(chǎn)的產(chǎn)品設(shè)計時可能是更好的選擇。

OpenEmbedded和Buildroot等專用構(gòu)建系統(tǒng)使用此模型，如debootstrap和multistrap等發(fā)行版打包工具。而Isar、debos和ELBE等新工具也使用這個基本模型。這樣的選擇還有很多，為企業(yè)的設(shè)計學(xué)習(xí)一個或多個這些包是值得投資的。這些系統(tǒng)的長期可維護性和可重復(fù)性將允許企業(yè)生成可重現(xiàn)的構(gòu)建、跟蹤所有源代碼，并消除企業(yè)對第三方提供商的依賴性，從而降低設(shè)計風(fēng)險。

結(jié)論

需要明確的是，分布式模型確實遇到了與Golden Maste模型相同的一些問題，尤其是對第三方的依賴。這是使用由他人設(shè)計的系統(tǒng)的結(jié)果，除非企業(yè)選擇自己完全采用的方法，而這種方法在開發(fā)和維護方面會帶來巨大的成本。

對于原型設(shè)計和概念驗證級別設(shè)計，以及由少數(shù)開發(fā)人員組成的團隊，Golden Master模型可能是正確的選擇，因為在此階段的開發(fā)中存在時間和預(yù)算限制。對于小批量、高接觸設(shè)計，這可能是一個可接受的權(quán)衡生產(chǎn)使用。

對于一般生產(chǎn)用途，團隊規(guī)?？蓴U展性、映像再現(xiàn)性、開發(fā)人員生產(chǎn)力方面的好處大大超過了實現(xiàn)分布式模型的系統(tǒng)的學(xué)習(xí)曲線和開銷。板卡和芯片供應(yīng)商的支持也在這些系統(tǒng)中廣泛使用，降低了使用它們進行開發(fā)的前期成本。對于企業(yè)推出的新產(chǎn)品，建議在認真考慮用于生成基本操作系統(tǒng)映像的模型的情況下啟動設(shè)計。如果企業(yè)選擇使用Golden Master模型進行原型設(shè)計以轉(zhuǎn)移到分布式模型，需要確保在企業(yè)的計劃中為此工作提供足夠的時間;根據(jù)企業(yè)選擇的具體工具以及要求的范圍，以及企業(yè)的代碼所依賴的軟件包的開箱即用的可用性，其估算值會有很大差異。

責任編輯：ct