从Linux on arm到Windows on arm

构建新的通用计算架构生态是个世界级难题，技术本身不是最难的部分，最难的点有两个：一个是得有丰富的应用生态，用户才能获得较好的用户体验；另一个是要有很大的出货量，这样才有成本优势。这两个条件互锁，类似于先有鸡还是先有蛋的问题，那要如何破局呢？

ARM是一个擅长做生态，且有成功记录的公司。它最擅长耐心，日拱一卒，以5年，10年为节奏，去完成听起来朴实低调，但其实特别宏大，以至于像吹牛一样的目标，例如，Linux on arm， Works on arm， Windows 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，才开始的数据中心生态建设，才真正是教科书一般的生态建设路线（一场硬仗）。

其实数据中心市场和移动计算市场非常不一样。数据中心市场是标准驱动的， 从系统该如何启动到软件如何大规模部署。更要命的是，数据中心发行版需要硬件提前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，然后发现软件世界的长尾效应非常长），还有了操作系统，但是这离繁荣的生态还有一大段距离呢。

生态，某种程度是开发者的生态。开发者的最低要求，是要有开发的环境，但是人手一台服务器，这个属实有点“钞”难度。但是云上的生态，可以云上解决部分。

从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生态移植到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 服务器进入一个新高度。