從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 服務器進入一個新高度。