说鸿蒙评论区总是攻击我是小米派来的,可以翻翻看看我以前的文章嘛。
小米14亮点还是有的,但是已经没有当年1999元定价那么惊艳了
看完后,是不是把菊花给整不会了?
菊花会不会说成黑完小米又黑华为啊?哈哈
其实你认为就是吊打你们这些NC粉就对了。
好,开始与菊花好好交流了
其他粉就纯当观看吧
开始扒一扒鸿蒙的微内核到底是啥了
系好安全带,我们出发吧!
本文回答的是菊花说的鸿蒙内核“完全自研”的说法(华为有没有这么说不重要,我回答的是大多的菊花的说辞)。“完全自研”指的是内核都出于华为研发的代码,不得使用第三方的源代码。
温馨提醒,关于鸿蒙内核的所有内容基于鸿蒙官方文档,想要打脸鸿蒙官方文档的话,希望你有足够的勇气,而不是只是懂得喊口号。
首先明确一下概念,鸿蒙系统一般华为使用的称为鸿蒙,也就是菊花口中说的商用版鸿蒙
华为把鸿蒙的核心代码开源了,成立的项目叫开源鸿蒙
这个就像安卓与开源安卓(AOSP)类似
下文提到鸿蒙,可能会不严格区分两者之间的关系
开源鸿蒙官方文档:https://docs.openharmony.cn/pages/v4.0/zh-cn/device-dev/kernel/kernel-overview.md/
做了那么多的铺垫,菊花都了解讨论的问题是啥了吧?
不清楚的再回去看看。
首先是开源鸿蒙对内核的定义:
业界的内核有很多,但无论是什么内核,基本上有几个最重要的组成单元是每个内核均要具备的,分别是:负责持久化数据,并让应用程序能够方便的访问持久化数据的“文件系统”。负责管理进程地址空间的“内存管理”。负责管理多个进程的“进程管理”或者“任务管理“。负责本机操作系统和另外一个设备上操作系统通信的“网络”。OpenHarmony采用了多内核结构,支持Linux和LiteOS,开发者可按不同产品规格进行选择使用。Linux和LiteOS均具备上述组成单元,只是实现方式有所不同。多个内核通过KAL(Kernel Abstraction Layer)模块,向上提供统一的标准接口。
https://docs.openharmony.cn/pages/v4.0/zh-cn/device-dev/kernel/kernel-overview.md/
我给你翻译一下,一个内核之所以能称为一个内核,需要同时具备文件系统、内存管理、进程管理、网络管理的能力,所以,基于这个认知,我认为只具备某一部分功能不能称为内核。
而且鸿蒙是根据设备选择不同的内核,一会用Linux内核,一会用LiteOS内核。
那么说鸿蒙基于Linux内核没什么不妥吧?
要么更准确一点是,鸿蒙是多内核的混合内核结构,本身基于LiteOS、Linux的内核。
菊花喷我说文件系统不是内核的说法,我觉得菊花说得对,“文件系统”确实不能称为内核,应该是属于内核的一部分。这不正是我之前所说的一样吗?我们讨论的问题就是鸿蒙内核是不是完全纯自研。只要我找了一个有其他的代码,那我就没必要找出所有了啊。
实锤!鸿蒙微内核LiteOS跟小米Vela一样用了NuttX内核代码
再看一下开源鸿蒙的内核说明:
OpenHarmony 轻量级内核是基于IoT领域轻量级物联网操作系统Huawei LiteOS内核演进发展的新一代内核,包含LiteOS-M和LiteOS-A两类内核。LiteOS-M内核主要应用于轻量系统,面向的MCU(Microprocessor Unit)一般是百K级内存,可支持MPU(Memory Protection Unit)隔离,业界类似的内核有FreeRTOS或ThreadX等;LiteOS-A内核主要应用于小型系统,面向设备一般是M级内存,可支持MMU(Memory Management Unit)隔离,业界类似的内核有Zircon或Darwin等。
https://docs.openharmony.cn/pages/v4.0/zh-cn/device-dev/kernel/kernel-small-overview.md/
说得清清楚楚,OpenHarmony也就是开源鸿蒙,用的是LiteOS内核。
逻辑思维能力强点的菊花可能会说,不对,你说的是内核,鸿蒙明明说了微内核的,你说的不是一个东西。
你是对的,鸿蒙这里用了内核的概念,并没有说“微内核”,他这里并没有提及,那鸿蒙官方都没有说微内核,我当然不敢说这就是微内核啊!要不菊花你问问鸿蒙写文档的,是不是搞错了?或者说这个微内核是未来的大饼,现在还不能吃。如果是大饼,那咱们就不来未来的东西了吧?
所以那些说鸿蒙基于微内核,linux基于宏内核的说法,我只知道余承东在PPT上有提到过,可能是未来鸿蒙的大饼。
如果你认为鸿蒙存在微内核,不是我说的这个LiteOS内核,你可以不看下面的内容了。
如果你承认鸿蒙用的内核是LiteOS,在这前提下继续看下文。
这个LiteOS又根据设备不一样,可以包含LiteOS-M和LiteOS-A两类内核。
看下LiteOS-A内核架构图:
内核空间中就包含有基础内核、文件系统、网络协议等,所以,文件系统是内核的一部分,菊花这么理解有问题吗?
再看看LiteOS-A内核它的代码结构:
/kernel/liteos_a
├── apps # 用户态的init和shell应用程序
├── arch # 体系架构的目录,如arm等
│ └── arm # arm架构代码
├── bsd # freebsd相关的驱动和适配层模块代码引入,例如USB等
├── compat # 内核接口兼容性目录
│ └── posix # posix相关接口
├── drivers # 内核驱动
│ └── char # 字符设备
│ ├── mem # 访问物理IO设备驱动
│ ├── quickstart # 系统快速启动接口目录
│ ├── random # 随机数设备驱动
│ └── video # framebuffer驱动框架
├── figures # 内核架构图
├── fs # 文件系统模块,主要来源于NuttX开源项目
│ ├── fat # fat文件系统
│ ├── jffs2 # jffs2文件系统
│ ├── include # 对外暴露头文件存放目录
│ ├── nfs # nfs文件系统
│ ├── proc # proc文件系统
│ ├── ramfs # ramfs文件系统
│ └── vfs # vfs层
├── kernel # 进程、内存、IPC等模块
│ ├── base # 基础内核,包括调度、内存等模块
│ ├── common # 内核通用组件
│ ├── extended # 扩展内核,包括动态加载、vdso、liteipc等模块
│ ├── include # 对外暴露头文件存放目录
│ └── user # 加载init进程
├── lib # 内核的lib库
├── net # 网络模块,主要来源于lwip开源项目
├── platform # 支持不同的芯片平台代码,如Hi3516DV300等
│ ├── hw # 时钟与中断相关逻辑代码
│ ├── include # 对外暴露头文件存放目录
│ └── uart # 串口相关逻辑代码
├── security # 安全特性相关的代码,包括进程权限管理和虚拟id映射管理
├── shell # 接收用户输入的命令,内核去执行
├── syscall # 系统调用
├── testsuilts # 测试套件
└── tools # 构建工具及相关配置和代码
来源:https://docs.openharmony.cn/pages/v4.0/zh-cn/device-dev/kernel/kernel-small-overview.md/
fs目录文件系统模块,主要来源于Nuttx开源项目。
认为开源鸿蒙内核LiteOS-A用了Nuttx代码有问题吗?
至于那些说用了英文是不是也要说用了英文这种回复就有点耍无赖了,典型的为了反驳而反驳。本来可以不回复的,但看得多这种回复了,就顺便打一下吧。说的是开源鸿蒙内核中有没有用了某个开源项目的代码,这帮人偷换概念说成有没有使用了英文字母,没有点逻辑思维能力的人会被这种人怼到无话可说。
其实根据开源鸿蒙对于内核的定义,开源LiteOS-A内核应该还包括网络模块,网络模块也说了主要来源于lwip开源项目。
所以可以总结一下:鸿蒙LiteOS-A内核不仅用了Nuttx的代码,也用了lwip的代码。
当AOSP跟OpenHamony都用了Linux的时候我给他画成这样吧,当然也有另外两种可能,也就是一种把Linux放在AOSP中,另一种是AOSP跟OpenHamony里面都有Linux。你觉得哪种更正确?
用了当然不代表什么,用了里面的一个小模块也算用了,但是你要注意鸿蒙官方的表述是“主要来源于”,意思是这个模块的功能实现主要靠这个来源的项目代码实现,当然也不是要说在文档摘要中列出所有来源,开源项目协议应该都有详细的要求,我相信开源鸿蒙在其它代码文件中应该是完全符合开源协议的要求的。
鸿蒙在官方文档摘要部分就列出主要使用的开源项目值得点赞,因为这让大多数能看懂中文的外行都能理解,让更多的人多了解一点鸿蒙内核的真相。省得互联网上少部分菊花认为鸿蒙内核是完全从零开始的纯国产自研的荒谬认知。
不管是基于某个开源项目,或者是用了某个开源项目的二次开发,我们都可以认为是自研,但是你用了别人的东西就要承认用了别人的东西,而不是说全都是你的东西,说用了别人的东西不丢人,不用遮遮掩掩的,光明正大使用就可以了,不丟人,这个要为开源鸿蒙点个赞。
菊花还有什么顾虑不承认用了某个开源项目的吗?说出来,不丢人。更不会死人。反而你要是大方承认,大家都给你点赞!
最后,再说一下微内核,不要认为用了微内核就会遥遥领先。
不要觉得微内核那么神
微内核相对宏内核有一个明显的缺点
微内核性能比宏内核差。
别以为微内核内核小就性能高,一开始我也是这么认为的。
但是深入了解你就会发现不是这样的。
是不是有点反直觉?
微内核小不是效率更高吗?
非也。
微内核的小是有代价的。
它的代价就是牺牲了性能。
那微内核和宏内核本质有什么区别呢?
可以用一个城市里的汽车生产工厂为例子,说一下他们之间的区别。
如果是宏内核,生产的汽车所用的原材料,如车轮、钢铁、玻璃等等都划在城市一个园区内,生产汽车的企业都可以从这个园区里面获得,他的生产效率是非常高的。
相反如果是微内核模式,应该是只保留装配车间,所有的其它原材料通过外部获取,这个外部可以是别的城市其他的城市运过来的,这个汽车装配车间就负责跟各种原材料的工厂沟通,叫他们把原材料运到汽车装配车间来,这样就出现了协调效率问题。比都集成在一个园区直接沟通效率要低。
但是微内核的好处是内核小,内核不容易出问题,所以大嘴宣传更稳定更小是没问题的。
宏内核由于集成的功能多,稳定性相对微内核没有那么稳定,一个模块出问题就会使得整个内核出问题。
所以,有些菊花说采用微内核系统整体流畅性比宏内核要流畅这个说法是错的。
先友好交流到这吧,这么多字应该菊花也没有认真看完就跟以往一样评论,不重要!不重要!哈哈