关于操作系统内核
我们先来普及一下操作系统内核知识，在操作系统设计中，内核是核心部分，负责管理硬件资源和系统服务，直接与硬件交互，而操作系统内核又分为宏内核、微内核。
宏内核特点：
1，高性能，所有服务都在内核空间运行，包括设备驱动，文件系统、网络协议等大量操作系统服务都在内核运行，由于都在内核空间运行，不需要频繁用户态和内核态切换，因此性能较高。
2，内核功能强大复杂，由于几乎所有操作系统核心服务都在内核中，所以内核代码庞大且复杂，带来维护和调试困难，当新加模块或修改内核都将面临引入新的问题所导致的稳定性，当模块出现错误影响整个系统。
微内核特点：
1，稳定性更好，代码精简，微内核只提供基本功能如进程通信而其他系统服务如文件系统都在用户空间运行，即使出现系统模块出错不会导致整个系统崩溃，只需重启该模块即可。
2，性能损耗，由于各服务都在用户空间，服务间不能直接调用而是通过消息传递通信，这就带来性能损耗，相比宏内核，微内核性能要低。
业界使用最多的基本是基于宏内核如Linux内核和Windows NT内核，当前国产操作系统基本基于Linux内核开发，Linux经过多年发展已经相当成熟应用在各个场景，而Linux内核是开源的所以不存在卡脖子问题。
微内核最具代表的如用于教学目的的Minix、实时操作系统QNX，其中最著名的当属Mach内核，以macOS、iPadOS和iOS为代表使用Mach内核。
Linux内核面临的问题
面向各种智能终端设备，Linux等宏内核的操作系统面临如下诉求：工业、汽车、医疗等更强的工业级安全要求，用户敏感数据保护。
Linux很难减少可信代码。过去4年1000个 CVE漏洞中大约70%可以通过合适的隔离避免。比较难满足工业、汽车、医疗等行业更强的工业级安全要求。
主线很难做特定领域的功能。Linux内核开发人员的行业分布主要面向服务端和云计算，在终端等方面关注较少。而Android系统上的很多设计很难合入主线。比如现在各手机厂商都在魔改公平调度CFS为面向QoS的调度方案。
下图是PREEMPT-RT Patch超过10年还没完全进入Linux主干。
2、更快的演进速度以跟上市场和研发设计
同步上游安全补丁的代价巨大。对企业来说，需要做各种回归测试，性能验证，有时候甚至要重写相关代码。
上图显示的2022年7个不同厂家的122款路由器中的大部分还在使用很老的Linux kernel 版本。
3、目前的微内核方案面临的问题
兼容性：
其它微内核方案预设了特定产品和场景，相关链条都有源码可以重新编译适配，对手机等终端却不现实，上百万的APP都重新编译，成百上千的设备驱动需要适配，难度可想而知。
资源管理和性能：
通过预分配的资源管理等限制了更好的全局协调管理。面向终端的系统，优先要考虑性能，兼顾安全，而常规微内核方案的性能比不上宏内核（Linus 和 Tanenbaum当年的宏内核和微内核之争）。
鸿蒙微内核详解
（鸿蒙微内核整体架构图）
主要从下面几个方面进行介绍：
Conventional Wisdoms | Problems | HongMeng Kernel | |
Minimality | Minimal Core Kerne | - | Retains Minimality |
IPC/lsolation | All Services at Userspace | Overly Strong Considering High IPC Frequency | Isolation Classes |
Service Partitioning | Static Multi-server | State Double Bookkeeping | Flexible Composition |
Control Access | Capabilities | Hide Kernel Objects | Address Tokens |
Interface | (subset-)POSIX | Require More than POSIX | ABl-compliant Shim |
Drivers | VM/Transplanting | Require Performant Reuse | Driver Containers |
保留微内核的最小化
保持微内核的最小化获得的收益。
Isolation Classes
现有微内核方案，高的IPC频率导致手机性能下降2到3倍：
服务分级方案：
Class 0 ：作为核心的受信代码基础。
Class 1 ：强机制隔离。严格限制跨域访问。IPC只包含轻量级的域交换。禁止特权指令。下层到kernel space。
Class 2 ：地址空间隔离。继续在user space。
IPC频率降低45%。
鸿蒙生态兼容性如何解决
对微内核来说，兼容性是头大的问题，对应用来说，POSIX做好都不容易：Linux下的poll和fork等API基于fd的方案，在微内核上fd分布在不同Service上，本身就很难做。
鸿蒙直接做ABI 二进制文件兼容：
通过在kernel space 增加一个Class 0级的ABI兼容垫片，做Linux syscall的重定向。这样对用户空间的大型二进制软件包都能兼容，比如AOSP，鸿蒙 APP等。
说完应用层兼容， 再说说驱动的适配。
700+多个驱动，靠全部重写，工作量超过5000人年，还有驱动是闭源的，不现实。业界目前提出的2种方案也存在兼容性和性能等问题：
鸿蒙通过Linux Driver Container方案解决驱动复用问题：
类似LKL/UML，在用户空间提供一个Linux Runtime。
DC-base 重定向 需要的 kernel API。重定向Kthread, Kernel Memory API到鸿蒙。DC-base 创建一个虚拟timer和一个虚拟IRQ chip来提供终端请求。这块工作量不大，比如从Linux 4.19升级到5.10修改不到100个变更。
Kernel Space端的Twin Driver处理IO IRQ，来应对性能敏感的path，比如UFS 驱动相关操作。init/suspend/resume这种很重的业务还是放到LDC中。
在UFS Block IO benchmark性能测试数据上看，鸿蒙和Linux 5.10上性能差不多。
鸿蒙与Linux内核基准测试对比
鸿蒙和Linux 基准测试对比：
鸿蒙在网络和上下文切换更优秀，内存和文件操作打平，fork和clone更差，但可以通过并行加速。
负载对比
在典型场景中，鸿蒙负载降低19%。
启动时间和丢帧
top 30 应用的启动时间测试，鸿蒙快17%。24小时丢帧率降低10%。
参考：OpenHarmony技术指导委员会创始主席、陈海波最新发表的《关于鸿蒙通用型微内核》的国际论文。
声明：以上内容部分来源haha视界，，仅供学习参考，不构成任何建议
最后，别忘了点“在看”
