手机
我来讲讲我的看法。这篇论文在开头就提及了两个场景，一个是智能
手机，另一个是智能
汽车，接着还提到了鸿蒙微内核最初应用的场景——
路由器（不过不清楚是家用
路由器还是运营商
路由器）。大家都明白，
Android的内核是
linux，而且在智能
汽车上，也有不少采用定制
Android作为车载娱乐系统的情况。然而，
linux的上游内核并没有任何安全认证，像ISO26262这种，所以不能直接在
汽车上使用。倒是一些下游的发行版，例如红帽，通过了ASIL - B级的认证。鸿蒙微内核则通过了ASIL - D级的认证，这是
汽车安全认证中最严格的级别。
linux存在一些特性，使得它无法应用于某些场景，这就促使了鸿蒙微内核的开发。
linux的主线是非常关键的，因为
linux不会维持内核API，两个长期支持（LTS）版本之间的变动非常大。如果代码无法提交到主线上，那就需要投入人力去进行移植，甚至是重写。总结有两点需求，一是
linux补丁的维护成本，二是智能
汽车对安全性、可靠性、可扩展性、性能以及可验证可认证性的需求。论文提到鸿蒙微内核这个项目已经开展了7年，开发时间是比较长的，主要代码是C语言的子集，总共9万行。（很遗憾的是，直到2023年才有经过ISO 26262 ASIL - D认证的Rust编译器，要是用Rust开发就好了。）除了
linux这个宏内核之外，论文还提到了3个微内核。2. 兼容
linux系统调用（syscall）和
linux设备容器在进一步剖析鸿蒙内核之前，我先对Zircon内核进行分析。Zircon是在littlekernel基础上进一步开发的微内核，它是采用功能受限的C ++语言编写的，是专门用于
Google Fuchsia操作系统的内核。鸿蒙微内核的开发背景与
linux内核的一些局限性紧密相关。
linux在
汽车领域的应用受限，主要是缺乏安全认证，这对于
汽车这种对安全性要求极高的设备来说是个很大的问题。而鸿蒙微内核通过了最严格的
汽车安全认证，这显示出它在安全性方面的优势。在开发过程中，
linux内核API的不稳定性也带来了麻烦，两个LTS版本间的巨大变动，使得代码如果不能提交到主线，就需要耗费大量人力去维护，这增加了开发成本。相比之下，鸿蒙微内核的开发在一定程度上是为了满足对维护成本、安全性等多方面的需求。从开发时长来看，7年的时间不短，这期间鸿蒙微内核的开发人员不断地对C语言子集编写的代码进行完善，最终形成了9万行代码。如果在开发初期就能有合适的工具，例如经过ISO 26262 ASIL - D认证的Rust编译器，也许开发过程会更加高效。再看其他微内核方面，论文提到的这3个微内核也是值得研究的内容。其中Zircon内核比较特殊，它基于littlekernel开发，专用于
Google Fuchsia操作系统，并且采用功能受限的C ++语言编写。这种语言的选择和它基于其他内核开发的模式，都反映了它的独特性。在智能
汽车领域，安全性、可靠性、可扩展性、性能以及可验证可认证性这些需求都非常重要。
linux内核由于缺乏安全认证，不能直接用于
汽车，这就凸显了鸿蒙微内核通过ASIL - D级认证的价值。对于
汽车制造商来说，一个通过严格安全认证的内核，能够让他们在开发车载系统时更加放心。在
linux内核的维护方面，其主线的不稳定性以及API的不维持，给开发人员带来了很大的困扰。补丁维护成本高，代码移植和重写的需求，都增加了开发的复杂性和成本。而鸿蒙微内核的开发，在一定程度上可以避免这些问题，更好地满足现代智能设备，特别是智能
汽车的需求。对于鸿蒙微内核自身来说，其主要代码为C语言子集这一特点，也反映了开发团队在选择开发语言时的考量。虽然现在Rust编译器有了相关认证，但在当时开发的时候，C语言子集也许是基于多种因素的最佳选择。在研究鸿蒙内核之前先分析Zircon内核，有助于我们从更广泛的角度来理解微内核的多样性和独特性。不同的微内核有着不同的设计目标和应用场景，Zircon内核为
Google Fuchsia操作系统服务，这与鸿蒙微内核的应用场景有着明显的区别。通过对这些不同微内核的研究，我们能够更好地把握微内核技术的发展脉络和各自的特点。
