linux
鸿蒙内核为微内核架构（更多创新可于7月osdi论文公开后查看），然而仍有不少诸如是否基于
linux、是否套壳、含多少
linux代码、不开源是否违反GPL之类的评论。本想无视，但有人会问为何不说，是不是不敢说，其实只要认真读一读论文摘要，就不会有此疑问了。有必要再次澄清：鸿蒙内核是由陈海波老师带领
华为内核实验室的数百人，历经多年从零开发而成。这是一个基于微内核架构的通用操作系统内核，已全面商用，像tee、部分管道设备、车等领域都有应用。它涵盖了调度、内存管理、文件系统、中断、信号、进程管理等所有内核核心组件，这些组件都是重新设计与实现的。鸿蒙内核旨在以API、ABI兼容的方式，承接海量北向应用（无需修改）生态；以用户态进程级Driver Cont
AIner方式，承接南向驱动（只需极少量适配）生态。在用户态LDC里有
linux驱动代码，遵循GPL协议，不过仅限于慢速设备。像UFS、GPU等需要性能或特权级支持的设备，已全面基于鸿蒙内核Native DC接口重写，并且Native DC和LDC之间有地址空间隔离。说句题外话，如果将来有人愿意基于鸿蒙内核Native DC接口重写慢速设备驱动代码（闭源的无法处理），那么这种情况下的鸿蒙内核就可以不包含任何一行
linux代码了。鸿蒙内核采用南北向兼容设计，能支持
linux的绝大多数场景，像嵌入式、终端（
手机、平板、PC）、智能车，甚至计算、云等场景也可支持。目前支持的有AOSP、鸿蒙Next等（便于性能基线对比）。鸿蒙因自身设计，在嵌入式、终端、车这类少核且对可扩展性要求不高的场景，比
linux有显著优势。而在众核计算场景，由于暂无项目开展，缺乏需求也就没有对应设计，与
linux相比存在较大差距。论文尚未公开，只能在摘要部分澄清。工作量大，只能趁午饭时间来澄清。我很少看评论区，大家不必再在评论区不停展示逻辑思维了。若对鸿蒙内核感兴趣，且想和我们一起干一番大事业的
同学，欢迎联系我们。我们有多地可供入职，像
北京、
上海、
南京、
深圳、
杭州，还有国外的德累斯顿、莫斯科、渥太华。
原回答我全程参与鸿蒙内核开发，在不违反信息安全的情况下，简单说几点。单纯比较两个内核的微观性能没什么太大意义。即便加上定语从流畅度来看，虽然增加了一定的可比性，但在测试用例不明确时，只能做定性分析，不太会有一方完全碾压或超越另一方的情况。即便测试用例明确，像业界典型的lmbench、geekbench等性能测试基准，也是各有胜负，很少有单方面的胜利。举个简单例子，通常宏核的所有内核对象状态是统一集中式管理，而微内核由于服务地址空间隔离，很多状态分散在各个组件。仅考察fork这个语义，微内核无论如何也比不上宏核的水平，这也是很多微内核不支持fork的原因，更不用说微核IPC的传统性能瓶颈了。所以在学术界，正常比较两个系统或子系统时，首先会固定变量，然后得出类似如下的对比数据：
可参考atc18 - bouron.pdf (usenix.org)中的比较两个调度器的方式。不过，通常这种比较很难判定谁优谁劣。要是有同学对鸿蒙内核和linux在细节以及benchmark（基准测试）方面的对比感兴趣，不妨等等Microkernel Goes General: Performance and Compatibility in the HongMeng Production Microkernel | USENIX这一内容，7月它就会公开了。但多数microbench领先就能表明内核超越了吗？答案是否定的。系统的终极目标是用户体验，而这是个复杂的系统工程，我们莫要陷入不服跑个分的误区，要认清跑分没赢过，体验没输过背后的逻辑。linux是全球众多优秀程序员历经数十年合作的成果，但它并非普适万能的。强调这点是为了让大家清楚一个概念：软件乃至世界上任何抽象事物（包括政治制度）都不存在绝对的好坏优劣，只有适合与否。开源软件的发展犹如一棵正在茁壮成长的树苗，大家给予的需求决定着它成长的方向。linux在通用服务器领域是基础，长期被Intel和Red Hat掌控，不断朝着服务器操作系统方向发展。一个仅有8核、16核的桌面系统或者小型终端设备，真的需要复杂的NUMA balance算法吗？为了可扩展性，有必要把每个内核对象都设计得极为复杂吗？需要耗费高昂的底层资源去做很多特定场景的事情吗？这就是当年CK提出linux能很好地支持4096核，可为何我播放flah时却卡顿的原因。
华为
还有一个极为严重的问题，
linux堪称分层解耦的范例，能支持世界上的绝大多数设备，可它居然没有完善的QoS软硬抽象（垂直整合）。这其实不难理解，因为
服务器运行的都是超级应用，只要在运行就属于重要且合理的任务。然而，这样的设计，在云混部场景以及终端场景下，简直就是个灾难。我在19年的OS2ATC上曾做过一个主题演讲，介绍
linux调度器存在哪些问题，以及我们为何如此重视QoS。有兴趣的可以查看这里：OS2ATC：操作系统调度器的演进_23628.pdf (debian.cn)
linux也在朝着一些定制化场景努力，像
谷歌、
Meta这些新玩家就在推动。要是感兴趣的话，可以去看看sched_ext的上游（upstream）进程。只能说这个进程很艰难、很曲折。这里面有没有利益纷争？（参考：sched: Implement BPF extensible scheduler class）我们可以对鸿蒙内核已经超越
linux内核这一说法加以改进。可以这样表述：鸿蒙内核是一种更契合终端通用场景的操作系统内核。在那些要求确定性低时延（
linux的实时补丁十多年都未能全部整合到上游，熟悉
linux的人应该都知晓realtime:documentation:start (
linuxfoundation.org)）、需要考虑续航以及极低功耗的用户场景中，鸿蒙内核的工作表现更佳，也更为适用（例如其调度底噪仅为
linux的25% - 50%）。不过要是直接将鸿蒙内核应用于计算领域，就目前的代码状况而言，其表现恐怕难以令人十分满意。3、有人提出，
linux是开源的，那它是否会被卡脖子，是不是在做重复工作？鸿蒙内核的开发者中，不少人有着十来年的
linux开发经验，如果仅仅通过简单裁剪、拉分支就能解决问题，就没必要自研内核了。
linux的低内聚、高耦合，其调度、内存管理等传统内核组件根本无法单独替换，更谈不上实时替换，这种缺乏弹性的情况难以适应未来多变的场景与硬件形态。安全性一直是宏核架构的难题。还有，很多人觉得开源就是无国界、无垄断的，仿佛世界
大同，这其实是一知半解，他们不懂得有人的地方就有纷争。为什么Arm想要合并big.LTTLE的EAS代码需要耗费五六年的努力？为什么精心打造的schedfreq说被schedutil取代就被取代了？为什么
谷歌要在主线之外另立分支来维护？说回归主线已经说了多少次了。又为什么有开发者宣称以后不再审核俄罗斯开发者提交的代码？哎，都懒得细说了。 以上。
