從Linux on arm到Windows on arm

構建新的通用計算架構生態是個世界級難題，技術本身不是最難的部分，最難的點有兩個：一個是得有豐富的應用生態，用戶才能獲得較好的用戶體驗；另一個是要有很大的出貨量，這樣纔有成本優勢。這兩個條件互鎖，類似於先有雞還是先有蛋的問題，那要如何破局呢？

ARM是一個擅長做生態，且有成功記錄的公司。它最擅長耐心，日拱一卒，以5年，10年爲節奏，去完成聽起來樸實低調，但其實特別宏大，以至於像吹牛一樣的目標，例如，Linux on arm， Works on arm， Windows on arm。

Linux on arm

Linux是什麼時候開始支持arm的？

第一次把Linux移植到ARM上是在1994，ARM成立之前。ARM的前身Acorn計劃把1.0.x的linux kernel移植到Acorn A5000上。當時的目標是在A5000上得到一個類Unix的操作系統， 而且沒有想過把結果返回到Linus的kernel tree上，因此只是一次移植，並不算Linux支持arm。

移植過程跟現在的應用移植區別也不大，把源碼包解壓縮，配置kernel，編譯。不過整個過程是非常曲折的。當時沒有配置腳本，需要手工編輯makefiles， 編輯頭文件，比較費時費力。kernel是分段編譯的，文件系統，kernel，ipc等都是單獨編譯。內存管理（mm）系統需要重寫，因爲物理頁和邏輯地址空間的映射關係反了。幸好那時的A5000相對簡單，因此驅動就沒有太大問題。但是彙編相關的所有內容都需要重寫。所有模塊都編譯通過之後，就需要把它們鏈接爲完整的kernel。第一次鏈接不出意料的失敗了，返回了一長串的未定義字符。經過一個月的修補， 終於Linux啓動了。隨後根盤（root disk），文件系統，shell程序，C庫等等，沒有一項是一次性通過，都是需要一番修補調試或者重寫才能正常工作。

最早支持ARM的正式發行版是Debian。2000年8月15日，Debian2.2 （Potato）支持了Intel i386，Motorola 68000 series, alpha, SUN Sparc, PowerPC 和ARM 架構（多麼百花齊放的2000年），其中 PowerPC和ARM都是新移植的。這個版本由450個Debian開發者，維護了3900多個二進制文件和2600多個源碼包。在那個時候，就有近上千個應用，需要測試。而且在2000年，還沒有平板，chrome books 或者現在的智能手機。一些工程師用康柏的iPaqs（還有多少人，記得康柏？）進行測試。

但是從此之後，Linux 與arm就一帆風順了麼？並沒有，2011年3月Linus Torvalds那封著名“the whole ARM thing is a f*ck pain in the ass”郵件，震驚了這個Linux社區，對ARM軟件團隊也是一個很大的觸動。本來ARM是屬於佛系努力派的，就是雖然努力，但是也很佛系，能做則做，能支持則支持，力所不能及的就隨緣了，最後總有需要的這項工作的一個或者幾個ARM系公司把它做了。但是這封要求arm加強控制的社區郵件，其實指出了由於ARM的IP授權模式，會出現多個不同的SOC提供商需要修改相同的Linux文件來支持自己的硬件的問題。重複工作效率低雖然是問題，但彼此之間有衝突，纔是致命。沒有人管理的衝突，最終的結局是分裂。

其實arm已經意識到存在生態分裂到問題，在這份“F”開頭的郵件之前的一年，就成了了Linaro，這個獨立的非盈利的工程師組織。Arm希望Linaro以中立的身份，組織 arm陣營的所有合作伙伴，解決Linux Kernel 和GNU工具鏈方面問題，形成合力夯實軟件生態。Linaro也確實做到了，僅僅一年的時間，就讓懟天懟地地Linus Torvalds換了讚許的態度。

歪一句，那封“Fx”郵件是回覆OMAP團隊的一個pull請求，現在讀起來唏噓OMAP今何在？有人說ARM幸運地搭上Androids的車， 可是如果當年Symbian贏（諾基亞的），Symbian的車上也是ARM。大家以爲ARM是移動計算市場的幸運者，其實是屍橫遍野之後的倖存者。

如果說移動計算市場，arm還是有先發優勢的，那麼2011年才發佈64位的ARMv8，纔開始的數據中心生態建設，才真正是教科書一般的生態建設路線（一場硬仗）。

企業版Linux on ARM

其實數據中心市場和移動計算市場非常不一樣。數據中心市場是標準驅動的， 從系統該如何啓動到軟件如何大規模部署。更要命的是，數據中心發行版需要硬件提前upstream所需的代碼和改動，然後才能在部署中實現對新硬件的支持。而且數據中心的架構也在不停的演進着，從Open Stack到K8s … …。因此ARM聯合自己陣營的生態夥伴們組隊制定標準，移植測試，保證互操作性，配合多種編排軟件，甚至推動開源軟件社區的多指令架構的軟件架構策略… 做了很多事情以確保在數據中心中所需要的海量開源軟件，在ARM架構上既可用也性能良好。

紅帽在2015年的峰會上，展示了從2011年開始，到2015年6月，紅帽團隊爲ARM生態而做的重要事件里程碑。這4年多的時間裡，紅帽開始移植OpenJDK的工作，和Linaro一起成立了Linaro企業組（後來更名爲Linaro數據中心組LDCG，把網絡分離出來成爲另外一個工作組），制定SBSA/SBBR標準，發佈Fedora社區版加速upstream活動，最終完成OpenJDK的移植任務，發佈RHEL預覽版。紅帽的參與，集成，穩定三步走策略也是非常經典，每個參與ARM生態的開源軟件社區基本都經歷了這三步曲。

不僅僅是紅帽，Canonical（Ubuntu），SUSE，OpenEuler，FreeBSD對於AArch64的支持，都是按年來進行工作計劃的。而這僅僅是操作系統層而已。

有了基礎的標準SBSA/SBBR，基礎的編譯工具GCC，LLVM（其實在編譯工具上，ARM還曾經走過一段彎路，前瞻性的全力以赴LLVM，階段性放棄了GCC，然後發現軟件世界的長尾效應非常長），還有了操作系統，但是這離繁榮的生態還有一大段距離呢。

生態，某種程度是開發者的生態。開發者的最低要求，是要有開發的環境，但是人手一臺服務器，這個屬實有點“鈔”難度。但是雲上的生態，可以雲上解決部分。

Works on ARM

從2017年開始， Packet（Equinix公司）和ARM一起啓動Works on ARM這個項目，提供免費的ARM雲主機的訪問，以此爲起點撬動更多的開源軟件社區在arm64架構上進行開發測試工作。

到2022年年末的現在，可以申請免費雲主機資源的可不僅僅是Packet，還有AWS， Google cloud，微軟的Azure， 拿樹莓派做服務器的MiniNode，俄勒岡州立大學的OSL，甲骨文雲和國內的騰訊雲。

但是Works on ARM的主要成果，並不僅僅是它的免費硬件資源，也不是這個項目支持了50多個著名的開源軟件項目。而是在這個項目的撬動下，CI/CD工具完全打通。

本來CI/CD的最流行工具是Jenkins，Drone.IO作爲後入者，也有一個要擴大生態的問題，同時受到Docker提倡的多指令集架構的鼓舞，Drone.IO團隊把支持arm架構作爲一個重要突破方向，2018年8月正式宣佈支持arm架構。Drone.IO對arm的支持是雙贏的，在宣佈支持arm的支持之後，其服務業務有10倍速的增長。

在Drone.IO的帶動下，其它幾個主要CI/CD的玩家也紛紛行動。2019年10月 Travis CI 在其支持的多CPU架構列表中正式加入了arm。幾乎在相同時間， Gitlab宣佈其64-bit Runner可以在Packet和AWS的arm實例上運行。2021年3月 CircleCI宣佈支持arm架構。2021年5月Jenkins 和甲骨文的OCI團隊一起合作，實現對arm實例的支持。

覆盤一下整個CI/CD生態都很好的支持了arm服務器的過程，這是一個長達5年的一個項目一個項目的遷移努力，也是天時加人和的結果：ARM一方面推動開源社區支持的多CPU架構策略，另一方面順利搭上built in the cloud快車，把arm雲實例帶到雲原生的產品迭代流程中。對於軟件來說，特別是雲原生軟件， 可移植的架構無關的軟件會有更好的生命力。一個原生的支持多架構的CI/CD流程，也能保證其上的軟件產品的穩定性和可移植性，CI/CD on ARM是一個雙贏的結果。

到目前爲止，Works on ARM的成果，除了CI/CD平臺之外，語言和編譯器也非常豐富，包括Eclipse Adoptium (之前的Adopt OpenJDK)， GNU的工具鏈， GoLang， LLVM， Node.JS， OpenJ9， Python， Rust 和Swift；操作系統和虛擬化軟件有Alpine Linux， CentOS， Cloud Hypervisor， Debian， Gentoo， KVM， OpenEmbedded (之前的 Yocto)。數據庫ScyllaDB也利用項目的硬件系統來樣子性能和程序的正確性。

如果再看看AWS， 谷歌雲，微軟Azure，甲骨文OCI，上跑在ARM實例上的軟件應用，可以很中肯的說，ARM在數據中心上的生態已經可以打A算是優等生了。

不過一直非常能整活的大神Linus說“在一個ISA推廣的初期，可供軟件工程師測試的硬件平臺是一個關鍵門檻。一個幾個人的小團隊，小公司也可以負擔得起的小PC盒子，工程師可以把自己的代碼運行在上面，自由測試，然後這樣的應用如果得到高速發展，在數據中心中心中落地，這就是真正的服務器應用。”，他的結論是，如果沒有ARM PC，也就沒有ARM服務器的未來。從歷史上看，Intel也確實是先拿下PC市場，然後再把一衆經典RISC處理器擠出了數據中心。

那麼問題來了，是ARM不喜歡PC市場，纔沒有大舉進攻PC市場麼？

（在這個問題上，讓我們跳過蘋果這一章，蘋果的生態做得好，但是一般人學不來）

Windows on ARM （WOA）

把Windows生態移植到arm上的努力，開始的很早，第一個成果就是2012年的微軟Surface Window RT。但在2012年，拋開硬件性能拉垮之外，生態方面差距太大，ARM的系統只能運行部分已經預先編譯過的應用，哪怕是Chrome、Photoshop都不能安裝… …

2018年微軟再次嘗試Windows on ARM時，已經完全吸取前次教訓。正式發佈的Window10 for ARM，可以支持arm設備跑任何存在的Windows應用。Windows 10操作系統是完全重新編譯的， DLL（也就是多數的Windows 庫）也都是重新編譯過的，部分應用已經是編譯過的原生arm應用，其它應用則採用動態二進制翻譯技術，將應用代碼轉換爲ARM64代碼執行。

二進制翻譯是Windows on ARM的答案麼？不，這僅僅是博一個開端而已。微軟和ARM的策略都是支持Windows on ARM的原生應用開發，從贏得開發者的心開始， 從端到端的工具鏈開始構建一個強壯的生態系統。

微軟團隊自己動手移植Visual Studio 2022, VSCode, VC++ toolchain, classic .NET Framework, modern .NET 和Java的工具鏈，同時和arm，開源社區一起移植通用工具，運行時，框架和庫。微軟Azure提供arm的虛擬機和CI/CD工具，同時還提供Windows Dev Kit 2023 （Project Volterra）硬件小盒子給開發者。

2019年11月發佈的Electron 6.0.8 算是一個開端， 2022年10月發佈的原生的Visual Studio 2022 version 17.4纔是大菜一盤。

而且微軟2022年2月加入Linaro，對就是Linaro，不知道Linaro會不會把自己的口號從Linux On arm改成all on arm … … 。Linaro的WOA項目頁，非常樸素，有介紹有項目列表，還有一張已經徐徐展開的路標圖，每一頁，每個標註都是軟件生態的一次遷徙。

我不知道別人看好Windows on ARM筆記本的哪裡，是電池待機時間長，5G一直在線，方便與手機同步，還是超薄超輕無風扇設計？我希望windows on ARM在PC市場上迅速成功，以帶動ARM 服務器進入一個新高度。