精华内容
下载资源
问答
  • 关于鸿蒙OS的一些看法

    万次阅读 多人点赞 2020-09-13 08:26:08
    缘起昨天晚上在CSDN做了一个关于鸿蒙OS的观点交流。可惜受限于宾馆的网络条件,有些想法没有表达清楚。再加上交流过程中,也从其他老师那了学到了一些观点。故写下此文。以下以QA方式对我(结...

    缘起

    昨天晚上在CSDN做了一个关于鸿蒙OS的观点交流。可惜受限于宾馆的网络条件,有些想法没有表达清楚。再加上交流过程中,也从其他老师那了学到了一些观点。故写下此文。以下以QA方式对我(结合了其它老师)参与回答的问题和观点进行了回顾。

    Q1:本次鸿蒙2.0 发布,让您感受最深的一点是什么?您看好鸿蒙吗?

    我个人非常清晰的体会是鸿蒙不仅仅是针对智能手机的OS。作为一个简单对比,它应该是包含了Android、Android Things、Android Wear、Android Auto等一系列覆盖从IoT到车机再到智能手机的OS们。从目前已知的情况看,这套OS的发展规划是先解决iot,然后逐步上升到智能手机这样的高端设备上。

    我个人觉得这是一种务实的做法。在逐步发展过程中可以试错。其中,一个比较关键的阶段是128M-4G这个设备,会涉及到一些内核之外的关键技术,比如图形/图像模块的开发,多媒体系统、应用安装和管理等


    总体来说,我更关注在鸿蒙发展壮大过程中自己(或者大部分普通开发者)能做什么,能学到什么、能积累什么。我觉得只盯着鸿蒙OS未来结果是没有太大意义的。在鸿蒙OS发展过程中所培育的人才,所收获的经验教训才是技术上的星星之火。


    关于这点,每一个关注过Android Fwk的同学都会有深深的感受。例如SurfaceFlinger中最开始连VSYNC都没有。谷歌也是在以肉眼明显可见的速度在不断改进。我个人最畏惧的国内的IT研发状况是,很多事情只做0到1的工作,从1到N的工作就不闻不问。这种风气和价值观导向会严重干扰和阻挠我们的进步。

    Q2:下面想请老师们解读下鸿蒙的机遇和可能遇到的挑战。

    我个人定义鸿蒙OS组合的发展策略走得是一条农村包围城市的道路。先从量大的IOT设备开始,逐步上升到中端设备,再到智能手机这样的高端设备。借助分布式,设备虚拟化等概念,打造所谓的超级终端。

    发布会后,我和一些小伙伴沟通过,有很多人觉得分布式这个概念不是很好懂,也不清晰。我这里冒昧做一些猜测,尝试解释下整个概念背后的思考逻辑。

    华为的核心强项之一是它在通信/连接这块有着非常深厚的技术积累。而分布式最重要和关键的问题是如何解决设备之间的高效和稳定的连通。所以,分布式是华为在设备间联通能力的一个自然而然的升华。

    接着说为什么有虚拟化设备(或者设备虚拟化)的概念。这是因为看问题的视角不一样。我在做IoT(是的,你没看错,我做了一年多的IoT,和中移动物联网一起做的)的时候,从上层应用角度来看,我更倾向于把IoT设备看成是数据源,我其实不太关心也不想关心摄像头、传感器是哪家的(很多时候这涉及到设备的采购,非常麻烦),上面跑的是单片机还是OS,底层通信协议是NB-IOT还是LoRa。我只希望这些传感器按约定好的数据传输和交互就行了。

    这种把外部设备看做是数据源/数据目的端是非常通用(我甚至觉得是比设备虚拟化更抽象)的看法,比如我早年间做的DLNA就是这样。

    从华为角度看,如果通过数据这种抽象(其背后是协议的功劳)将硬件差异化都屏蔽了的话,鸿蒙的IoT OS就没有办法渗透到设备上去了。所以,分布式+设备虚拟化是将鸿蒙OS渗透到IoT设备上的关键支撑。

    以上推测是非常粗陋的。昨天蒋总补充了几点,他也问过王博(华为CBG软件部总裁王成录)类似的问题。答复是其中还有一些上面没提到的关键技术细节,比如软总线、设备间的软时钟同步等。意思是华为在分布式和虚拟化设备这两块是实实在在把远程设备当做本地设备在处理了(而不是我之前那种将它们看做数据源的方式,这种方式相对比较简单)。

    另外,鸿蒙这种做法的风险是什么?我个人觉得,虽然众多设备被虚拟化,分布式部署了,但目前来看毕竟还是有一个中枢系统——就是1+8+N中的1,手机。如果手机被掐脖子,就是单点问题,风险非常高。一个可能的解决办法就是将这套分布式、设备虚拟化的技术的协议标准化,让其他家手机也支持。

    另外,这里还忽略了边缘计算设备的存在感。边缘计算的核心是把来自更底层设备(比如传感器)的数据进行加工处理以提高响应速度。比如,车机就是一个边缘计算器,它会把大量的来自车载传感器的数据进行处理(如果这些数据发给一个云端服务器再处理的话时效性就很差,无法处理紧急情况)。在这种模式下,分布式,设备虚拟化就很难再渗透到车机之下的众多传感器了。

    有没有可能这套实现了分布式、设备虚拟化的技术赋能给非华为的公司?这不是一个幼稚的问题。看看高通,再看看SONY集团卖摄像头芯片的(对外部的大客户比对自家的SONY移动支持度更好)、以及三星卖存储、显示屏、甚至CPU芯片,他们的客户都不局限在集团内部。

    Q3:明年华为智能手机将全面使用鸿蒙,很多开发者关心鸿蒙是否真的能替代安卓系统,对此您怎么看?

    此问题原文不是这么问的,大致是这么个意思。我的观点如下:

    太多人纠结鸿蒙未来能不能取代安卓系统。这是个封闭性的问题,答案为是或者不是。我们不妨换个思路看这个问题。假设鸿蒙取代了安卓,皆大欢喜,大家回家洗洗睡。如果没取代安卓又怎样?微软没干成,三星没干成,又如何呢?这妨碍微软不牛吗,三星不牛吗?

    再者,在这个开发OS的过程中,我们难道毫无收获?显然不是,我们会培养,造就大量的OS方面的人才,这是多么大的一笔财富。前几个月神农班上某同学跑到清华去找合作,想找几个搞webkit底层的同学,结果人家博导说学生们都去搞AI,区块链这些能赚钱的事情了。

    我们一方面痛恨打着完全自主开发名号的OS、浏览器,一方面又把所有希望不合理的强加在一个公司上,这像是踏踏实实一步一个脚印搞研发的心态么?我个人觉得,中国要做到真正自主可控(注意,我说的是自主可控,意思是鬼子一旦撒手跑了,我们自己也能干。自主可控不是一个什么高大上的名称,凡是用过外包的企业都会要求这一点)的OS,浏览器,编译器至少还需要10年到20年的时间。如果没有华为这样的公司砸钱搞基础技术研发,这个时间恐怕还得大大延长。

    现在国家、很多公司都在往基础技术上做投入,这是一个好时代,非常感谢大洋对面的金毛及其团队。最后,科技竞争是一个长期的、艰苦的、胶着反复的过程,大家做好打持久战的准备即可。

    Q4:关于国产操作系统,我们还有很多路要走,请大家给一些建议和看法。

    我是作为一名普通开发者身份参与这次直播对话的。普通开发者构成了当前对鸿蒙乃至国产OS的评论主体,我觉得有必要传达和引导一种正向的,积极的态度。

    首先,作为一名普通开发者,碰到当前世界处于百年未有之大变局的时候,应该抱着积极心态主动参与。虽然神农班的班规中提倡个人自由表达不同的观点,但我觉得情绪宣泄过后,是不是可以考虑要不要做点什么?不做就没有收获。当然,一切都自便,大家开心就好。

    其次,要树立功成不必在我,功成必定有我的心态。这个心态并不是说压迫你干活还不给钱,而是说不要把“必须成功”当成个人甚至团队的唯一目标了。我们打得是持久战,注意积累,培养。很大可能是其他人会站在你们的肩膀上继续战斗乃至获得最终的成功。

    最后,星星之火可以燎原,OS以及更多基础核心技术自主可控的这面红旗无论如何都要竖起来,扛下去,我相信大家对此已经没有争议了。在这里希望能有更多人,甚至国外的开发者一起参与开发、建设、生态的培养等。

    恩,确实还有很多事情可以做,很多知识可以学,岂不乐哉?

    最后的最后

    • 我期望的结果不是朋友们从我的书、文章、博客后学会了什么知识,干成了什么,而应该是说,神农,我可是踩在你的肩膀上的喔。

    • 关于学习方面的问题,我已经讨论完了。后面这个公众号将对一些基础的技术,新技术做一些学习和分享。也欢迎你的投稿。不过,正如我在公众号里说的那样——郑渊洁在童话大王《智齿》里有一句话令我印象深刻,大意是“我有权保持沉默,但你说的每一句话都可能成为我灵感的源泉”。所以,影响不是单向的,很可能我从你那学到的东西更多。

                                                                                      神农和朋友们的杂文集

                                                                                      长按识别二维码关注我们

    展开全文
  • 鸿蒙OS

    千次阅读 2020-11-18 10:53:51
    一、鸿蒙OS是什么? 华为公司新近推出的经历十年多时间自主研发的鸿蒙操作系统(HarmonyOS),是基于微内核的全场景分布式OS,可按需扩展,实现更广泛的系统安全 。目前主要用于智能物联网,在将来无法使用Android时...

    一、鸿蒙OS是什么?
    华为公司新近推出的经历十年多时间自主研发的鸿蒙操作系统(HarmonyOS),是基于微内核的全场景分布式OS,可按需扩展,实现更广泛的系统安全 。目前主要用于智能物联网,在将来无法使用Android时可扩展到智能手机上。HarmonyOS拥有分布架构、内核安全、生态共享、运行流畅四大优势,鸿蒙OS生态的两大核心要素包括自身的微内核结构和方舟编译器。

    二、HarmonyOS的特点
    1.HarmonyOS的设计与理念
    鸿蒙OS是全新的基于微内核的面向全场景的分布式操作系统。鸿蒙OS的微内核已发展到seL4,如下图(图1所示)。seL4的核心非常小,不到9000行C代码。对于微内核,由于用内存管理单元MMU对进程空间进行隔离保护,没有授权的进程将无法访问其他进程的空间,从而阻止了恶意程序对其他进程数据的窃取。鸿蒙OS核心只保留了处理的时间、内存、通信、中断等基本的资源管理,所有其他功能由应用层来管理,以服务的形式去提供功能。服务之间采用进程间通信IPC。
    在这里插入图片描述
    鸿蒙OS实现模块化耦合,对应不同设备可弹性部署;首次将分布式架构用于终端OS,实现跨终端无缝协同体验;采用的确定时延引擎和高性能IPC技术使系统更流畅;其基于微内核架构可重塑终端设备安全性;通过统一IDE支撑一次开发,多端部署,实现跨终端生态共享。

    2.HarmonyOS的创新
    2.1 内部解耦
    为适应不同的硬件,鸿蒙OS把每一层内部都解耦,形成几千个模块,每个模块的接口全部用头文件写好,打上标签说明该模块是怎样的设备。可针对应不同设备进行弹性部署,如智慧屏、穿戴设备、车机、音箱、手机等,同时创新的分布式软总线使得拥有不同功能的硬件可以彼此协同。如传统的相机、电视、音响等设备原本相互独立,利用鸿蒙的分布式软总线,这些设备可被虚拟化成摄像模组、显示模组、外放模组,并成为有机整体,用户无需另行设置即可按需调用各种功能,硬件终端之间形成相互协同。

    2.2 虚拟硬件
    创新性地打破传统终端硬件的边界,使诸如手机中的显示器、处理器芯片、内存等等实体硬件,可以通过软件按需求组合成不同硬件形态的虚拟硬件功能模块。

    2.3 一次开发多端部署
    通过用户接口UI控件的抽象和解耦,业务逻辑原子化,不同应用的适配,可以快速实现一次开发并进行多端部署。鸿蒙OS从设计之初就为多,终端而生,如边缘计算、IoT、服务器等。

    2.4 分布式微内核
    鸿蒙OS的微内核所具有的分布式特点,有利于IoT的生态协同。现有各种操作系统只对应于某一种硬件,如Windows只对应x86 PC、iOS对应苹果手机等,无法满足IoT时代众多不同种类终端的需要,也无法针对每种硬件分别开发一种操作系统或应用程序,导致不同硬件终端的生态无法共享协同,开发效率低。因此鸿蒙OS在IoT应用中的优势更加明显。

    3.方舟编译器特点分析
    方舟编译器是华为2019年4月在P30系列手机发布会上公布的,定位于多终端系统,可协助鸿蒙操作系统进入更深层次布局边缘计算、服务器等领域,大幅提升手机端安卓系统的运行效率。

    3.1 编译点提前
    方舟编译器能够在应用程序执行之前,就将Java代码编译成机器语言,从而大量释放硬件资源,这对于多终端,尤其是物联网边缘计算尤为重要。克服了传统编译器边执行边翻译导致的程序执行效率低下,以及安卓系统虚拟机程序安装时间长的不足。方舟编译器将编译过程提前至开发环节,开发者能通过方舟预置算法进行代码优化,还可自行开发代码优化算法,未来代码优化甚至有可能迁移至云端。

    3.2 开发环境友好
    开发环境友好是鸿蒙搭建良好生态的重要因素。兼容Java和C、C++等多种语言,增强了鸿蒙OS的性能,并与自有麒麟、鲲鹏等硬件架构协同,形成类似微软和英特尔联盟的软硬件格局。克服了过去采用Java和C/C++等多种语言混合开发应用程序时,传统编译器下跨语言应用执行效率较低的问题。
    在这里插入图片描述
    4.HarmonyOS的应用研究
    鸿蒙OS的出现将导致与iOS和Android成三足鼎立之势。尽管华为的鸿蒙OS目前只作为5G手机中Android的备胎,据已公开的资料,鸿蒙OS的UI设计、系统逻辑以及App安装界面,与现在华为手机上的EMUI并没有明显区别,这使现有EMUI用户可以尽快习惯新系统,降低学习成本。此外,由于鸿蒙OS与Android保持兼容,通过方舟编译系统,原来的应用还能够提速60%以上。

    鸿蒙OS的应用领域如图2所示。可应用于手机专有服务、智慧屏专有服务、穿戴设备专有服务、车机专有服务、音箱专有服务等领域,还可使这些不同设备协同工作,切换设备时实现无缝衔接。

    鸿蒙OS使手机、电脑、汽车、智能穿戴等设备的操作系统实现兼容,有利于物联网的升级管理和兼容,成为将来走向智能社会的一个操作系统。

    鸿蒙OS与具有高速、低延时、广接入的5G相结合,为智能手机与智能穿戴设备的联动、智能自动驾驶汽车、物联网系统提供了新的基础技术支撑。

    华为鸿蒙(HarmonyOS)支持多种协议混合适配不同业务场景,用100多种品类的控制组件,向开发者提供最丰富的连接方式。由于华为做了30多年通信,连通本来就是强项,这点是意料之中。
    在这里插入图片描述
    用“1+8+N”来总结华为的战略,就显得很直观。

    1:手机是一个核心入口;

    8:PC、平板、智慧大屏、车机、耳机、音箱、手表、眼镜这八个大小屏入口;

    N:摄像头、路由器、冰箱、空调等N种泛物联网设备。

    HarmonyOS把各终端硬件的能力虚拟成可共享的能力资源池,让应用通过系统调用其所需的硬件能力。在这个架构下,硬件能力,类似活字印刷术中的一个个单字字模,可以被无限次重复使用。简单来说,各终端实现了硬件互助,资源共享;应用拥有了调用远程终端的能力(像调用本地终端一样方便);而用户收获一个多设备组成的超级终端。

    结束
    猛一看,鸿蒙系统占据着绝对的劣势。但从纵观移动操作系统十几年的起起伏伏,鸿蒙系统并非没有机会。在2007年第二季度,塞班系统占据着63.75%的市场份额,Windows Mobile及BlackBerry OS则分别占据10&左右市场份额

    虽然目前主流操作系统大多被国外垄断,我国华为公司的HarmonyOS虽然起步不久,但却具有许多独特优势,其改进的跨平台功能、支持多场景应用、可以在各种设备和平台上使用、可以满足消费者对低延迟和强安全性需求的特点,使其具有广阔的应用前景。

    在硬件和软件之间,中国产业界一向“重硬轻软“。毕竟,硬件更容易被消费者感知,加一个摄像头、上一个大屏幕,用户一眼就看到了,发布会和营销都好找噱头。但是,软件,尤其是基础软件的革新,用户感知有很大很大的滞后性。因此,企业对于基础软件的投资,常常不被理解,甚至引来冷嘲热讽,这背后,是中国产业界普遍浮躁、急功近利的心态。

    从华为的历史来看,它是一家十分耐得住寂寞的公司。往远了说,80年代创业之初代理交换机就很赚钱,任正非却偏偏要赌上一切搞如此高风险的自主研发;往近了说,当年海思何曾被被看好过,最初几代产品也是在你我的嘲笑中成长,最终十年磨一剑,终成大器。

    以上内容节选自取自HarmonyOS特点与应用前景分析:四川工业科技学院电子信息与计算机工程学院 李艳\刘丹\田小东\谭琦

    原文
    https://blog.csdn.net/harmonycommunity/article/details/108796421?utm_medium=distribute.pc_feed.455628.nonecase&depth_1-utm_source=distribute.pc_feed.455628.nonecase

    展开全文
  • 鸿蒙OS是什么

    万次阅读 多人点赞 2020-09-25 14:41:54
    文章目录前言一、鸿蒙OS是什么?二、HarmonyOS的特点1.HarmonyOS的设计与理念2.HarmonyOS的创新3.方舟编译器特点分析4.HarmonyOS的应用研究结束 前言 提示: 2019年8月华为推出鸿蒙HarmonyOS,并运用在荣耀智慧屏,...

    前言

    提示: 2019年8月华为推出鸿蒙HarmonyOS,并运用在荣耀智慧屏,HDC 2020,华为消费者业务软件部总裁王成录将在9月11日进行《共建、共享 HarmonyOS 生态》的演讲,将分享 HarmonyOS 2.0发布的新进展以及给人们、给行业带来的价值。


    提示:以下是本篇文章正文内容,下面案例可供参考

    一、鸿蒙OS是什么?

    华为公司新近推出的经历十年多时间自主研发的鸿蒙操作系统(HarmonyOS),是基于微内核的全场景分布式OS,可按需扩展,实现更广泛的系统安全 。目前主要用于智能物联网,在将来无法使用Android时可扩展到智能手机上。HarmonyOS拥有分布架构、内核安全、生态共享、运行流畅四大优势,鸿蒙OS生态的两大核心要素包括自身的微内核结构和方舟编译器。

    二、HarmonyOS的特点

    1.HarmonyOS的设计与理念

    鸿蒙OS是全新的基于微内核的面向全场景的分布式操作系统。鸿蒙OS的微内核已发展到seL4,如下图(图1所示)。seL4的核心非常小,不到9000行C代码。对于微内核,由于用内存管理单元MMU对进程空间进行隔离保护,没有授权的进程将无法访问其他进程的空间,从而阻止了恶意程序对其他进程数据的窃取。鸿蒙OS核心只保留了处理的时间、内存、通信、中断等基本的资源管理,所有其他功能由应用层来管理,以服务的形式去提供功能。服务之间采用进程间通信IPC。
    在这里插入图片描述
    鸿蒙OS实现模块化耦合,对应不同设备可弹性部署;首次将分布式架构用于终端OS,实现跨终端无缝协同体验;采用的确定时延引擎和高性能IPC技术使系统更流畅;其基于微内核架构可重塑终端设备安全性;通过统一IDE支撑一次开发,多端部署,实现跨终端生态共享。

    2.HarmonyOS的创新

    2.1 内部解耦 为适应不同的硬件,鸿蒙OS把每一层内部都解耦,形成几千个模块,每个模块的接口全部用头文件写好,打上标签说明该模块是怎样的设备。可针对应不同设备进行弹性部署,如智慧屏、穿戴设备、车机、音箱、手机等,同时创新的分布式软总线使得拥有不同功能的硬件可以彼此协同。如传统的相机、电视、音响等设备原本相互独立,利用鸿蒙的分布式软总线,这些设备可被虚拟化成摄像模组、显示模组、外放模组,并成为有机整体,用户无需另行设置即可按需调用各种功能,硬件终端之间形成相互协同。

    2.2 虚拟硬件 创新性地打破传统终端硬件的边界,使诸如手机中的显示器、处理器芯片、内存等等实体硬件,可以通过软件按需求组合成不同硬件形态的虚拟硬件功能模块。

    2.3 一次开发多端部署 通过用户接口UI控件的抽象和解耦,业务逻辑原子化,不同应用的适配,可以快速实现一次开发并进行多端部署。鸿蒙OS从设计之初就为多,终端而生,如边缘计算、IoT、服务器等。

    2.4 分布式微内核 鸿蒙OS的微内核所具有的分布式特点,有利于IoT的生态协同。现有各种操作系统只对应于某一种硬件,如Windows只对应x86 PC、iOS对应苹果手机等,无法满足IoT时代众多不同种类终端的需要,也无法针对每种硬件分别开发一种操作系统或应用程序,导致不同硬件终端的生态无法共享协同,开发效率低。因此鸿蒙OS在IoT应用中的优势更加明显。

    3.方舟编译器特点分析

    方舟编译器是华为2019年4月在P30系列手机发布会上公布的,定位于多终端系统,可协助鸿蒙操作系统进入更深层次布局边缘计算、服务器等领域,大幅提升手机端安卓系统的运行效率。

    3.1 编译点提前
    方舟编译器能够在应用程序执行之前,就将Java代码编译成机器语言,从而大量释放硬件资源,这对于多终端,尤其是物联网边缘计算尤为重要。克服了传统编译器边执行边翻译导致的程序执行效率低下,以及安卓系统虚拟机程序安装时间长的不足。方舟编译器将编译过程提前至开发环节,开发者能通过方舟预置算法进行代码优化,还可自行开发代码优化算法,未来代码优化甚至有可能迁移至云端。

    3.2 开发环境友好
    开发环境友好是鸿蒙搭建良好生态的重要因素。兼容Java和C、C++等多种语言,增强了鸿蒙OS的性能,并与自有麒麟、鲲鹏等硬件架构协同,形成类似微软和英特尔联盟的软硬件格局。克服了过去采用Java和C/C++等多种语言混合开发应用程序时,传统编译器下跨语言应用执行效率较低的问题。
    在这里插入图片描述

    4.HarmonyOS的应用研究

    鸿蒙OS的出现将导致与iOS和Android成三足鼎立之   势。尽管华为的鸿蒙OS目前只作为5G手机中Android的备胎,据已公开的资料,鸿蒙OS的UI设计、系统逻辑以及App安装界面,与现在华为手机上的EMUI并没有明显区别,这使现有EMUI用户可以尽快习惯新系统,降低学习成本。此外,由于鸿蒙OS与Android保持兼容,通过方舟编译系统,原来的应用还能够提速60%以上。

    鸿蒙OS的应用领域如图2所示。可应用于手机专有服务、智慧屏专有服务、穿戴设备专有服务、车机专有服务、音箱专有服务等领域,还可使这些不同设备协同工作,切换设备时实现无缝衔接。

    鸿蒙OS使手机、电脑、汽车、智能穿戴等设备的操作系统实现兼容,有利于物联网的升级管理和兼容,成为将来走向智能社会的一个操作系统。

    鸿蒙OS与具有高速、低延时、广接入的5G相结合,为智能手机与智能穿戴设备的联动、智能自动驾驶汽车、物联网系统提供了新的基础技术支撑。

    华为鸿蒙(HarmonyOS)支持多种协议混合适配不同业务场景,用100多种品类的控制组件,向开发者提供最丰富的连接方式。由于华为做了30多年通信,连通本来就是强项,这点是意料之中。
    在这里插入图片描述
    用“1+8+N”来总结华为的战略,就显得很直观。

    1:手机是一个核心入口;

    8:PC、平板、智慧大屏、车机、耳机、音箱、手表、眼镜这八个大小屏入口;

    N:摄像头、路由器、冰箱、空调等N种泛物联网设备。

    HarmonyOS把各终端硬件的能力虚拟成可共享的能力资源池,让应用通过系统调用其所需的硬件能力。在这个架构下,硬件能力,类似活字印刷术中的一个个单字字模,可以被无限次重复使用。简单来说,各终端实现了硬件互助,资源共享;应用拥有了调用远程终端的能力(像调用本地终端一样方便);而用户收获一个多设备组成的超级终端。

    结束

    猛一看,鸿蒙系统占据着绝对的劣势。但从纵观移动操作系统十几年的起起伏伏,鸿蒙系统并非没有机会。在2007年第二季度,塞班系统占据着63.75%的市场份额,Windows Mobile及BlackBerry OS则分别占据10&左右市场份额

    虽然目前主流操作系统大多被国外垄断,我国华为公司的HarmonyOS虽然起步不久,但却具有许多独特优势,其改进的跨平台功能、支持多场景应用、可以在各种设备和平台上使用、可以满足消费者对低延迟和强安全性需求的特点,使其具有广阔的应用前景。

    在硬件和软件之间,中国产业界一向“重硬轻软“。毕竟,硬件更容易被消费者感知,加一个摄像头、上一个大屏幕,用户一眼就看到了,发布会和营销都好找噱头。但是,软件,尤其是基础软件的革新,用户感知有很大很大的滞后性。因此,企业对于基础软件的投资,常常不被理解,甚至引来冷嘲热讽,这背后,是中国产业界普遍浮躁、急功近利的心态。

    从华为的历史来看,它是一家十分耐得住寂寞的公司。往远了说,80年代创业之初代理交换机就很赚钱,任正非却偏偏要赌上一切搞如此高风险的自主研发;往近了说,当年海思何曾被被看好过,最初几代产品也是在你我的嘲笑中成长,最终十年磨一剑,终成大器。

    【如果您想学习HarmonyOS 应用开发基础教程 请猛戳】

    以上内容节选自取自HarmonyOS特点与应用前景分析:四川工业科技学院电子信息与计算机工程学院 李艳\刘丹\田小东\谭琦

    展开全文
  • 本文对鸿蒙OS内核进行了简单的分析,涉及鸿蒙OS内核的架构,鸿蒙OS内核的三大核心模块(进程管理,虚拟内存,文件系统)。首先,作者先阐述几个关键的名词。操作系统(Operating System): 操作系统的功能是负责管理各种...

    本文对鸿蒙OS内核进行了简单的分析,涉及鸿蒙OS内核的架构,鸿蒙OS内核的三大核心模块(进程管理,虚拟内存,文件系统)。

    首先,作者先阐述几个关键的名词。

    操作系统(Operating System): 操作系统的功能是负责管理各种硬件设备,同时对底层硬件设备进行抽象,为上层软件提供高效的系统接口。操作系统设计和实现的优劣直接决定了系统栈的各个方面,比如性能,可靠性,甚至安全性。操作系统的设计实现是计算机系统研究最古老最困难的方向之一。因为底层设备的复杂性,操作系统实现的代码量巨大。从系统架构上可以将操作系统分为三类:宏内核(Monolithic Kernel)操作系统,微内核(Microkernel)操作系统,外内核(Exokernel)操作系统。

    内核(kernel): 几乎所有的处理器厂商都将处理器的执行状态分为了两个级别:特权级(priviledge)和非特权级(non-priviledge)。处理器只有在特权级时才可以执行一些特权级的指令和访问特殊的寄存器。特权级和非特权级的划分是为了防止不可信的用户和应用程序破坏系统的状态和数据。特权级又称为ring 0。在特权级执行的代码称为内核。所以,内核实际上是一段在处理器特权级执行的代码。只不过代码量越写越大,最后变成了软件。

    操作系统与内核的关系。狭义上讲,操作系统指的就是内核。比如Linux内核,所有的操作系统代码都在核心态执行,这样的操作系统称为宏内核操作系统。但是随着操作系统技术的不断发展,操作系统本身的架构也在不断的演进。一些操作系统为了追求架构设计的简洁和系统的安全性,将部分操作系统模块的代码从内核态剥离出来,放到用户态执行(比如Minix操作系统)。这样内核只包括了少量的核心功能模块,在极大的程度上简化了内核的设计和实现。而剥离到用户态的操作系统代码可以以服务进程的方式去运行,或者以库的形式存在(Library OS),链接到其他的内核上去。

    鸿蒙OS内核包括了liteos-a内核和liteos-m内核。liteos-m内核是最早面向物联网设备开发的,内存要求小于128MB。而liteos-a针对的是资源较为丰富的嵌入式设备,内存可以达到4GB。本文分析的是liteos-a内核。

    鸿蒙OS内核的架构

    鸿蒙OS内核最主要的特性之一就是微内核的操作系统内核架构设计。那么如何分析操作系统设计采用的内核架构呢?一个简单直接的方法就是观察操作系统内核接口的设计。操作系统内核接口又称为系统调用(System Call)。操作系统内核接口的设计体现了操作系统内核本身设计的复杂度。比如Linux内核作为宏内核的代表,系统调用数量在325个。几乎全部的操作系统功能实现都在内核中。Windows内核的系统调用数量据说有上千个。而微内核的代表的操作系统内核Minix,最早其系统调用的数量仅仅为2个。内核对上层软件只提供了消息传递的服务功能。下面通过鸿蒙OS内核的系统调用实现来简单分析一下鸿蒙OS内核的架构。

    鸿蒙OS运行库采用了第三方的musl libc库。在musl libc库中,系统调用的实现是应用程序在寄存器中设置好系统调用号和系统调用参数后,执行svc指令陷入到内核,如下面代码所示:

    static inline long __syscall3(long n, long a, long b, long c)

    {

    register long r7 __ASM____R7__ = n; // 系统调用号

    register long r0 __asm__("r0") = a; //参数0

    register long r1 __asm__("r1") = b; // 参数1

    register long r2 __asm__("r2") = c; // 参数2

    do { \

    __asm__ __volatile__ ( "svc 0" \

    : "=r"(r0) : "r"(r7), "0"(r0), "r"(r1), "r"(r2) : "memory"); \

    return r0; \

    } while (0);

    }

    liteos-a内核在函数OsArmA32SyscallHandle中处理这个中断。函数OsArmA32SyscallHandle根据系统调用号执行预先设置好的系统调用服务例程。

    LITE_OS_SEC_TEXT UINT32 *OsArmA32SyscallHandle(UINT32 *regs)

    {

    UINT32 ret;

    UINT8 nArgs;

    UINTPTR handle;

    UINT32 cmd = regs[REG_R7];

    if (cmd >= SYS_CALL_NUM) {

    PRINT_ERR("Syscall ID: error %d !!!\n", cmd);

    return regs;

    }

    if (cmd == __NR_sigreturn) {

    OsRestorSignalContext(regs);

    return regs;

    }

    handle = g_syscallHandle[cmd];

    nArgs = g_syscallNArgs[cmd / NARG_PER_BYTE]; /* 4bit per nargs */

    nArgs = (cmd & 1) ? (nArgs >> NARG_BITS) : (nArgs & NARG_MASK);

    if ((handle == 0) || (nArgs > ARG_NUM_7)) {

    PRINT_ERR("Unsupport syscall ID: %d nArgs: %d\n", cmd, nArgs);

    regs[REG_R0] = -ENOSYS;

    return regs;

    }

    switch (nArgs) {

    case ARG_NUM_0:

    case ARG_NUM_1:

    ret = (*(SyscallFun1)handle)(regs[REG_R0]);

    break;

    case ARG_NUM_2:

    case ARG_NUM_3:

    ret = (*(SyscallFun3)handle)(regs[REG_R0], regs[REG_R1], regs[REG_R2]);

    break;

    case ARG_NUM_4:

    case ARG_NUM_5:

    ret = (*(SyscallFun5)handle)(regs[REG_R0], regs[REG_R1], regs[REG_R2], regs[REG_R3],

    regs[REG_R4]);

    break;

    default:

    ret = (*(SyscallFun7)handle)(regs[REG_R0], regs[REG_R1], regs[REG_R2], regs[REG_R3],

    regs[REG_R4], regs[REG_R5], regs[REG_R6]);

    }

    regs[REG_R0] = ret;

    OsSaveSignalContext(regs);

    /* Return the last value of curent_regs. This supports context switches on return from the exception.

    * That capability is only used with theSYS_context_switch system call.

    */

    return regs;

    }

    liteos-a内核中的全部系统调用都定义在文件syscall/los_syscall.h中。通过观察这个文件可以发现liteos-a类似于Linux内核,定义了大量的系统调用,并且这些系统调用全部都实现在内核态当中。

    syscall/los_syscall.h

    extern unsigned int SysGetGroupId(void);

    extern unsigned int SysGetTid(void);

    extern void SysSchedYield(int type);

    extern int SysSchedGetScheduler(int id, int flag);

    extern int SysSchedSetScheduler(int id, int policy, int prio, int flag);

    extern int SysSchedGetParam(int id, int flag);

    extern int SysSchedSetParam(int id, unsigned int prio, int flag);

    extern int SysSetProcessPriority(int which, int who, unsigned int prio);

    extern int SysGetProcessPriority(int which, int who);

    extern int SysSchedGetPriorityMin(int policy);

    ....

    相比于传统的微内核,liteos-a内核稍显复杂。微内核最主要的代表Minix操作系统,其系统接口设计简洁到只有两个系统调用:发送消息send和接收消息receive。任何的系统调用请求都用消息封装好,然后在用户态的服务进程之间互相传递。内核只提供了三个基本的功能:时钟中断,进程调度和消息传递。

    笔者统计了一下鸿蒙OS内核的代码量,如下表所示:

    liteos-a内核

    NuttX虚拟文件系统

    lwIP网络协议栈

    69265

    16056

    89485

    其中liteos-a内核将近7万行,NuttX虚拟文件系统1.6万行左右,lwIP网络协议栈近9万行。这十几万行的代码包含了操作系统最核心的几个功能模块(进程管理,虚拟内存,文件系统,网络传输),这些功能模块全部运行在内核态。目前liteos-a内核的实现在宏内核和微内核之间更偏向于宏内核。或许后期鸿蒙OS还会对其内核架构有进一步的调整。

    鸿蒙OS内核还有另外一个重要特点:安全性。鸿蒙OS内核的安全性可以通过其内核架构来保证。微内核架构因为其较小的内核设计实现,相比于宏内核庞大的功能实现,其大大减少了攻击面的大小。另外,微内核的架构也可以方便后期系统整体的形式化验证。鸿蒙OS内可能会借助于形式化技术来保证其内核设计实现的正确性。目前被验证系统的代码量与形式化技术验证软件系统需要的代码量比例大概在1:20左右。即一行c语言代码需要二十行形式化验证代码去验证。微内核简单的内核设计和极小的内核代码量无疑会大大减轻后期操作系统形式化验证的代码量。目前鸿蒙OS内核在开发时代码注释写的非常规范。如下图所示,猜测也是为了后期系统形式化验证时接口规约的方便。注释比代码长,囧。

    /**

    * @ingroup los_sys

    * @brief Obtain the number of cycles in one second.

    *

    * @par Description:

    * This API is used to obtain the number of cycles in one second.

    * @attention

    *

    *

    None

    *

    *

    * @param None

    *

    * @retval UINT32 Number of cycles obtained in one second.

    * @par Dependency:

    *

    • los_sys.h: the header file that contains the API declaration.

    * @see None

    */

    extern UINT32 LOS_CyclePerTickGet(VOID);

    总结一下鸿蒙OS内核架构的设计:

    优点: 微内核的设计简化了操作系统内核设计实现的复杂度,提高了系统的安全性和可靠性,减轻了后期形式化验证的工作量,:)。

    缺点: 目前liteos-a内核的设计实现更偏向于宏内核而不是微内核,囧z。

    鸿蒙OS内核的进程管理

    liteos-a内核同时支持了进程和线程的实现。进程描述符为LosProcessCB,线程描述符为LosTaskCB。

    进程描述符LosProcessCB包含了进程的所有信息:进程号,进程调度状态,进程信号状态,虚拟内存信息,文件系统状态,以及进程的权能信息。所有的进程描述符LosProcessCB的指针保存在一个全局的数组g_processCBArray中。通过processID进行索引,可以获得对应的LosProcessCB结构。系统中的所有进程通过childrenList,exitChildList,siblingList组织成一个树状的结构。capability字段是进程的权能信息,用来实现主体对客体资源的访问控制。

    typedef struct ProcessCB {

    CHAR processName[OS_PCB_NAME_LEN]; /**< Process name */

    UINT32 processID; /**< process ID = leader thread ID */

    UINT16 processStatus; /**< [15:4] process Status; [3:0] The number of threads currently

    running in the process */

    UINT16 priority; /**< process priority */

    UINT16 policy; /**< process policy */

    UINT16 timeSlice; /**< Remaining time slice */

    UINT16 consoleID; /**< The console id of task belongs */

    UINT16 processMode; /**< Kernel Mode:0; User Mode:1; */

    UINT32 parentProcessID; /**< Parent process ID */

    UINT32 exitCode; /**< process exit status */

    LOS_DL_LIST pendList; /**< Block list to which the process belongs */

    LOS_DL_LIST childrenList; /**< my children process list */

    LOS_DL_LIST exitChildList; /**< my exit children process list */

    LOS_DL_LIST siblingList; /**< linkage in my parent's children list */

    ProcessGroup *group; /**< Process group to which a process belongs */

    LOS_DL_LIST subordinateGroupList; /**< linkage in my group list */

    UINT32 threadGroupID; /**< Which thread group , is the main thread ID of the process */

    UINT32 threadScheduleMap; /**< The scheduling bitmap table for the thread group of the

    process */

    LOS_DL_LIST threadSiblingList; /**< List of threads under this process */

    LOS_DL_LIST threadPriQueueList[OS_PRIORITY_QUEUE_NUM]; /**< The process's thread group schedules the

    priority hash table */

    volatile UINT32 threadNumber; /**< Number of threads alive under this process */

    UINT32 threadCount; /**< Total number of threads created under this process */

    LOS_DL_LIST waitList; /**< The process holds the waitLits to support wait/waitpid */

    #if (LOSCFG_KERNEL_SMP == YES)

    UINT32 timerCpu; /**< CPU core number of this task is delayed or pended */

    #endif

    UINTPTR sigHandler; /**< signal handler */

    sigset_t sigShare; /**< signal share bit */

    #if (LOSCFG_KERNEL_LITEIPC == YES)

    ProcIpcInfo ipcInfo; /**< memory pool for lite ipc */

    #endif

    LosVmSpace *vmSpace; /**< VMM space for processes */

    #ifdef LOSCFG_FS_VFS

    struct files_struct *files; /**< Files held by the process */

    #endif

    timer_t timerID; /**< iTimer */

    #ifdef LOSCFG_SECURITY_CAPABILITY

    User *user;

    UINT32 capability;

    #endif

    #ifdef LOSCFG_SECURITY_VID

    TimerIdMap timerIdMap;

    #endif

    #ifdef LOSCFG_DRIVERS_TZDRIVER

    struct file *execFile; /**< Exec bin of the process */

    #endif

    mode_t umask;

    } LosProcessCB;

    与进程管理相关的系统调用包括fork,exit,wait等。这里看一下fork系统调用的实现。liteos-a内核中fork系统调用由SysFork函数实现,而SysFork函数主要由OsCopyProcess函数实现。

    STATIC INT32 OsCopyProcess(UINT32 flags, const CHAR *name, UINTPTR sp, UINT32 size)

    {

    UINT32 intSave, ret, processID;

    LosProcessCB *run = OsCurrProcessGet();

    /* 分配一个新的进程描述符 */

    LosProcessCB *child = OsGetFreePCB();

    if (child == NULL) {

    return -LOS_EAGAIN;

    }

    processID = child->processID;

    /* 初始化进程描述符 */

    ret = OsForkInitPCB(flags, child, name, sp, size);

    if (ret != LOS_OK) {

    goto ERROR_INIT;

    }

    /* 将父进程进程描述符中的信息拷贝到子进程描述符中,包括虚拟内存,文件,信号,权能等 */

    ret = OsCopyProcessResources(flags, child, run);

    if (ret != LOS_OK) {

    goto ERROR_TASK;

    }

    /* 设置新进程的状态并加入到调度队列中,等待被调度运行 */

    ret = OsChildSetProcessGroupAndSched(child, run);

    if (ret != LOS_OK) {

    goto ERROR_TASK;

    }

    LOS_MpSchedule(OS_MP_CPU_ALL);

    if (OS_SCHEDULER_ACTIVE) {

    LOS_Schedule();

    }

    return processID;

    ERROR_TASK:

    SCHEDULER_LOCK(intSave);

    (VOID)OsTaskDeleteUnsafe(OS_TCB_FROM_TID(child->threadGroupID), OS_PRO_EXIT_OK, intSave);

    ERROR_INIT:

    OsDeInitPCB(child);

    return -ret;

    }

    同一个进程的所有线程共享内核中的状态,比如打开文件,地址空间等。liteos-a中所有同一个进程的所有线程共享一个LosProcessCB结构体,进程描述符中的threadSiblingList表示该进程所有的线程。线程描述符为LosTaskCB中processID字段表示所属的进程。LosTaskCB结构其余的字段表示线程的信息,比如线程栈,线程运行的处理器等信息。

    typedef struct {

    VOID *stackPointer; /**< Task stack pointer */

    UINT16 taskStatus; /**< Task status */

    UINT16 priority; /**< Task priority */

    UINT16 policy;

    UINT16 timeSlice; /**< Remaining time slice */

    UINT32 stackSize; /**< Task stack size */

    UINTPTR topOfStack; /**< Task stack top */

    UINT32 taskID; /**< Task ID */

    TSK_ENTRY_FUNC taskEntry; /**< Task entrance function */

    VOID *joinRetval; /**< pthread adaption */

    VOID *taskSem; /**< Task-held semaphore */

    VOID *taskMux; /**< Task-held mutex */

    VOID *taskEvent; /**< Task-held event */

    UINTPTR args[4]; /**< Parameter, of which the maximum number is 4 */

    CHAR taskName[OS_TCB_NAME_LEN]; /**< Task name */

    LOS_DL_LIST pendList; /**< Task pend node */

    LOS_DL_LIST threadList; /**< thread list */

    SortLinkList sortList; /**< Task sortlink node */

    UINT32 eventMask; /**< Event mask */

    UINT32 eventMode; /**< Event mode */

    UINT32 priBitMap; /**< BitMap for recording the change of task priority,

    the priority can not be greater than 31 */

    INT32 errorNo; /**< Error Num */

    UINT32 signal; /**< Task signal */

    sig_cb sig;

    #if (LOSCFG_KERNEL_SMP == YES)

    UINT16 currCpu; /**< CPU core number of this task is running on */

    UINT16 lastCpu; /**< CPU core number of this task is running on last time */

    UINT16 cpuAffiMask; /**< CPU affinity mask, support up to 16 cores */

    UINT32 timerCpu; /**< CPU core number of this task is delayed or pended */

    #if (LOSCFG_KERNEL_SMP_TASK_SYNC == YES)

    UINT32 syncSignal; /**< Synchronization for signal handling */

    #endif

    #if (LOSCFG_KERNEL_SMP_LOCKDEP == YES)

    LockDep lockDep;

    #endif

    #if (LOSCFG_KERNEL_SCHED_STATISTICS == YES)

    SchedStat schedStat; /**< Schedule statistics */

    #endif

    #endif

    UINTPTR userArea;

    UINTPTR userMapBase;

    UINT32 userMapSize; /**< user thread stack size ,real size : userMapSize + USER_STACK_MIN_SIZE */

    UINT32 processID; /**< Which belong process */

    FutexNode futex;

    LOS_DL_LIST joinList; /**< join list */

    LOS_DL_LIST lockList; /**< Hold the lock list */

    UINT32 waitID; /**< Wait for the PID or GID of the child process */

    UINT16 waitFlag; /**< The type of child process that is waiting, belonging to a group or parent,

    a specific child process, or any child process */

    #if (LOSCFG_KERNEL_LITEIPC == YES)

    UINT32 ipcStatus;

    LOS_DL_LIST msgListHead;

    BOOL accessMap[LOSCFG_BASE_CORE_TSK_LIMIT];

    #endif

    } LosTaskCB;

    在鸿蒙OS的运行库中的pthread_create函数里,可以发现在创建线程时调用了__thread_clone函数。而__thread_clone函数则调用了SYS_creat_user_thread系统调用。代码路径third_party_musl/src/thread/pthread_create.c

    int __pthread_create(pthread_t *restrict res, const pthread_attr_t *restrict attrp, void *(*entry)(void *), void *restrict arg)

    {

    ...

    ret = __thread_clone((c11 ? start_c11 : start), flags, new, stack);

    ...

    }

    int __thread_clone(int (*func)(void *), int flags, struct pthread *thread, unsigned char *sp)

    {

    int ret;

    bool join_flag = false;

    struct user_param param;

    if (thread->detach_state == DT_JOINABLE) {

    join_flag = true;

    }

    param.user_area = TP_ADJ(thread);

    param.user_sp = sp;

    param.map_base = thread->map_base;

    param.map_size = thread->map_size;

    ret = __syscall(SYS_creat_user_thread , func, &param, join_flag);

    if (ret < 0) {

    return ret;

    }

    thread->tid = (unsigned long)ret;

    return 0;

    }

    内核在创建线程的函数OsCreateUserTask中,仅仅需要分配初始化一个LosTaskCB结构体。因此,在litos-a内核中,调度的实体是进程LosProcessCB,而不是线程。同一个进程创建出的多个线程依附在创建的进程上去运行。

    LITE_OS_SEC_TEXT_INIT INT32 OsCreateUserTask(UINT32 processID, TSK_INIT_PARAM_S *initParam)

    {

    ....

    if (processID == OS_INVALID_VALUE) {

    SCHEDULER_LOCK(intSave);

    processCB = OsCurrProcessGet(); /* 获得当前运行的进程processCB */

    initParam->processID = processCB->processID;

    initParam->consoleID = processCB->consoleID;

    SCHEDULER_UNLOCK(intSave);

    } else {

    processCB = OS_PCB_FROM_PID(processID);

    if (!(processCB->processStatus & (OS_PROCESS_STATUS_INIT | OS_PROCESS_STATUS_RUNNING))) {

    return OS_INVALID_VALUE;

    }

    initParam->processID = processID;

    initParam->consoleID = 0;

    }

    ret = LOS_TaskCreateOnly(&taskID, initParam); /* 分配LosTaskCB */

    if (ret != LOS_OK) {

    return OS_INVALID_VALUE;

    }

    return taskID;

    }

    小结: liteos-a内核本身不直接支持线程实现,将线程的信息和进程信息分离开。内核中调度管理的实体是进程,但是调度器中包含了线程的调度信息,比如调度的优先级。liteos-a内核不同于Linux内核,在Linux内核中采用的NPTL线程库中,每个线程在内核都有一个相应的进程控制块。另外,liteos-a内核进程管理的其他部分实现遵循传统的操作系统内核中的进程管理实现,包括进程调度,进程的创建回收,进程的组织,信号传递等。

    鸿蒙OS内核的虚拟内存

    虚拟内存包括了虚拟地址空间和页表树这两个主要的结构。虚拟地址空间被划分为若干的线性区。liteos-a内核中进程内存描述符结构为LosVmSpace,线性区描述符结构为VmMapRegion。进程所有的线性区描述符用两种数据结构组织:链表和红黑树。链表头regions,红黑树根节点regionRbTree。node表示全局的g_vmSpaceList链表节点。进程/线程在操纵虚拟地址空间时必须先获取互斥量regionMux。下面的一些字段描述符了进程地址空间的基本信息,比如堆的开始和结束地址,代码段的开始和结束地址。archMmu字段表示了页表的信息。

    typedef struct VmSpace {

    LOS_DL_LIST node; /**< vm space dl list */

    LOS_DL_LIST regions; /**< region dl list */

    LosRbTree regionRbTree; /**< region red-black tree root */

    LosMux regionMux; /**< region list mutex lock */

    VADDR_T base; /**< vm space base addr */

    UINT32 size; /**< vm space size */

    VADDR_T heapBase; /**< vm space heap base address */

    VADDR_T heapNow; /**< vm space heap base now */

    LosVmMapRegion *heap; /**< heap region */

    VADDR_T mapBase; /**< vm space mapping area base */

    UINT32 mapSize; /**< vm space mapping area size */

    LosArchMmu archMmu; /**< vm mapping physical memory */

    #ifdef LOSCFG_DRIVERS_TZDRIVER

    VADDR_T codeStart; /**< user process code area start */

    VADDR_T codeEnd; /**< user process code area end */

    #endif

    } LosVmSpace;

    每个线性区描述符结构为VmMapRegion。该结构体描述了线性区的基本信息,包括线性区的开始和结束LosVmMapRange,线性区的访问权限protectFlags,线性区的类型regionType。根据线性区映射类型的不同,分为三类:文件映射,匿名映射,特殊设备映射,即unTypeData。

    struct VmMapRegion {

    LosRbNode rbNode; /**< region red-black tree node */

    LosVmSpace *space;

    LOS_DL_LIST node; /**< region dl list */

    LosVmMapRange range; /**< region address range */

    VM_OFFSET_T pgOff; /**< region page offset to file */

    UINT32 regionFlags; /**< region flags: cow, user_wired */

    UINT32 shmid; /**< shmid about shared region */

    UINT8 protectFlags; /**< vm region protect flags: PROT_READ, PROT_WRITE, */

    UINT8 forkFlags; /**< vm space fork flags: COPY, ZERO, */

    UINT8 regionType; /**< vm region type: ANON, FILE, DEV */

    union {

    struct VmRegionFile {

    unsigned int fileMagic;

    struct file *file;

    const LosVmFileOps *vmFOps;

    } rf;

    struct VmRegionAnon {

    LOS_DL_LIST node; /**< region LosVmPage list */

    } ra;

    struct VmRegionDev {

    LOS_DL_LIST node; /**< region LosVmPage list */

    const LosVmFileOps *vmFOps;

    } rd;

    } unTypeData;

    };

    liteos-a内核中与虚拟内存相关的系统调用有mmap,munmap,brk,mprotect等。这里以mmap为例阐述一下liteos-a中虚拟内存管理的实现。mmap系统调用主要由函数LOS_MMap实现。函数LOS_MMap首先会进行参数的检查,然后对齐映射开始的地址和大小。接着判断一下是否是文件映射,如果是获取file结构体指针。下面获取保护虚拟地址空间的互斥量regionMux,因为线程共享地址空间,可能同时修改管理线性区的红黑树,所以要保证互斥访问。然后在进程的虚拟地址空间中查找一块未被使用过的区间,分配一个VmMapRegion结构体,将VmMapRegion结构体插入到红黑树中,这里并没有插入到链表中,可能实现还不完全,囧。最后根据线性区的类型设置标志,返回映射的开始地址。当进程/线程真正访问该线性区时,会触发缺页异常。内核在缺页异常里面会根据线性区信息来检查缺页地址的合法性,然后更新页表树结构。这里就不阐述了。

    VADDR_T LOS_MMap(VADDR_T vaddr, size_t len, unsigned prot, unsigned long flags, int fd, unsigned long pgoff)

    {

    STATUS_T status;

    VADDR_T resultVaddr;

    UINT32 regionFlags;

    LosVmMapRegion *newRegion = NULL;

    struct file *filep = NULL;

    LosVmSpace *vmSpace = OsCurrProcessGet()->vmSpace;

    vaddr = ROUNDUP(vaddr, PAGE_SIZE);

    len = ROUNDUP(len, PAGE_SIZE);

    STATUS_T checkRst = OsCheckMMapParams(vaddr, prot, flags, len, pgoff);

    if (checkRst != LOS_OK) {

    return checkRst;

    }

    if (LOS_IsNamedMapping(flags)) {

    status = fs_getfilep(fd, &filep);/* 判断一下是否是文件映射,如果是获取file结构体指针 */

    if (status < 0) {

    return -EBADF;

    }

    }

    /* 获取保护虚拟地址空间的互斥量regionMux */

    (VOID)LOS_MuxAcquire(&vmSpace->regionMux);

    /* user mode calls mmap to release heap physical memory without releasing heap virtual space */

    status = OsUserHeapFree(vmSpace, vaddr, len);

    if (status == LOS_OK) {

    resultVaddr = vaddr;

    goto MMAP_DONE;

    }

    regionFlags = OsCvtProtFlagsToRegionFlags(prot, flags);

    /* 分配一个VmMapRegion结构体 */

    newRegion = LOS_RegionAlloc(vmSpace, vaddr, len, regionFlags, pgoff);

    if (newRegion == NULL) {

    resultVaddr = (VADDR_T)-ENOMEM;

    goto MMAP_DONE;

    }

    newRegion->regionFlags |= VM_MAP_REGION_FLAG_MMAP;

    resultVaddr = newRegion->range.base;

    /* 根据线性区的类型设置标志 */

    if (LOS_IsNamedMapping(flags)) {

    status = OsNamedMMap(filep, newRegion);

    } else {

    status = OsAnonMMap(newRegion);

    }

    if (status != LOS_OK) {

    LOS_RbDelNode(&vmSpace->regionRbTree, &newRegion->rbNode);

    LOS_RegionFree(vmSpace, newRegion);

    resultVaddr = (VADDR_T)-ENOMEM;

    goto MMAP_DONE;

    }

    MMAP_DONE:

    (VOID)LOS_MuxRelease(&vmSpace->regionMux);

    return resultVaddr;

    }

    小结: liteos-a内核中虚拟内存管理类似于传统操作系统内核中的实现(比如Linux内核),无论是管理线性区的数据结构(红黑树+链表),实现的代码逻辑,地址空间管理的同步机制等。但是缺少相应的性能优化措施,比如线性区的缓存,相同权限的连续地址线性区的合并等。另外,目前虚拟内存系统调用实现还不完全,比如缺少madvise系统调用的实现。

    鸿蒙OS内核的文件系统

    liteos-a内核中文件系统包含了虚拟文件系统和具体文件系统实现。虚拟文件系统采用了第三方的NuttX系统,具体文件系统目前支持FAT,JFFS2,NFS,RamFS四种文件系统。liteos-a内核中文件系统的系统调用调用还是比较全面的,基本包含了所有常用的文件系统系统调用。进程描述符中的files_struct结构体描述了文件描述符的状态,包括文件描述符表等信息。其余的虚拟文件系统中涉及到的结构在NuttX系统中实现。所以,liteos-a内核只负责管理文件描述符信息。

    struct files_struct {

    int count;

    struct fd_table_s *fdt;

    unsigned int file_lock;

    unsigned int next_fd;

    #ifdef VFS_USING_WORKDIR

    spinlock_t workdir_lock;

    char workdir[PATH_MAX];

    #endif

    };

    Linux内核中的虚拟文件系统包含了四大对象:超级块super_block,索引节点inode,目录项dentry,文件对象file。NuttX虚拟文件系统简化了虚拟文件系统的实现,文件系统的元数据用fsmap_t结构体描述,没有目录项dentry结构。

    struct fsmap_t

    {

    const char *fs_filesystemtype;

    const struct mountpt_operations *fs_mops;

    const BOOL is_mtd_support;

    const BOOL is_bdfs;

    };

    索引节点inode保存了文件的元数据。在NuttX中的虚拟文件系统中,所有文件的inode会按照目录的层级组织成树的结构,树节点的指针是i_peer和i_child。inode结构体采用了文件的完整路径名进行索引,路径名字符串保存在i_name中。索引节点所有文件系统注册的操作函数保存在inode_ops_u结构体中。

    struct inode

    {

    FAR struct inode *i_peer; /* Link to same level inode */

    FAR struct inode *i_child; /* Link to lower level inode */

    int16_t i_crefs; /* References to inode */

    uint16_t i_flags; /* Flags for inode */

    unsigned long mountflags; /* Flags for mount */

    union inode_ops_u u; /* Inode operations */

    #ifdef LOSCFG_FILE_MODE

    unsigned int i_uid;

    unsigned int i_gid;

    mode_t i_mode; /* Access mode flags */

    #endif

    FAR void *i_private; /* Per inode driver private data */

    MOUNT_STATE e_status;

    char i_name[1]; /* Name of inode (variable) */

    };

    最后,每一个打开的文件都由一个file结构体来描述。

    struct file

    {

    unsigned int f_magicnum; /* file magic number */

    int f_oflags; /* Open mode flags */

    FAR struct inode *f_inode; /* Driver interface */

    loff_t f_pos; /* File position */

    unsigned long f_refcount; /* reference count */

    char *f_path; /* File fullpath */

    void *f_priv; /* Per file driver private data */

    const char *f_relpath; /* realpath */

    struct page_mapping *f_mapping; /* mapping file to memory */

    void *f_dir; /* DIR struct for iterate the directory if open a directory */

    };

    liteos-a内核中任何文件系统的元数据操作必须进行路径名查找操作。文件路径名查找操作会将用户给定的文件路径名转化成文件的索引节点inode。NuttX中的虚拟文件系统采用了完整的文件路径名进行查找操作。inode_find根据给定的文件路径名按照从上到下的顺序查找所有inode组织的树结构,在树的每一层按照从左向右的顺序,依次匹配树中的每个inode。该inode树结构由一个信号量来保证互斥访问。这里存在两个性能问题。第一,树查找操作没有采用优化措施,导致查找效率不高。第二,整个系统中只有这一个inode树结构,多进程并发访问时会造成非常严重的锁竞争问题,导致系统可扩展性能下降。

    作为对比,Linux内核对文件路径名查找操作进行了很多的优化。Linux内核中的虚拟文件系统采用了dentry结构组织成目录树,并且采用了哈希表以及RCU等多种方法来提高文件路径名查找的效率和可扩展性。

    int inode_find(FAR struct inode_search_s *desc)

    {

    int ret;

    FAR const char *path = desc->path;

    FAR const char **relpath = &(desc->relpath);

    FAR struct inode **peer = &(desc->peer);

    FAR struct inode **parent = &(desc->parent);

    /* Find the node matching the path. If found, increment the count of

    * references on the node.

    */

    inode_semtake();

    desc->node = inode_search(&path, peer, parent, relpath);

    if (desc->node != NULL)

    {

    /* Found it */

    FAR struct inode *node = desc->node;

    /* Increment the reference count on the inode */

    node->i_crefs++;

    ret = 0;

    }

    else

    {

    ret = -1;

    }

    inode_semgive();

    return ret;

    }

    完成文件路径名的查找操作之后,NuttX中的虚拟文件系统根据inode结构体中的inode_ops_u查找到对应的操作函数,调用具体文件系统注册的操作函数,进行具体文件系统的操作。这里不再阐述。

    小结: liteos-a文件系统只实现了文件描述符的管理,其余虚拟文件系统的实现借助与第三方的NuttX系统,并且在实现层移植了若干其他文件系统(比如FAT)。NuttX系统中虚拟文件系统存在很多的性能问题,比如文件路径名查找的可扩展性和效率都不太好。未来liteos-a内核可以自己实现了一个虚拟文件系统,而不是借用NuttX系统中的虚拟文件系统,毕竟NuttX系统中的虚拟文件系统实现并不是太好。

    总结

    这次鸿蒙OS开源的内核功能上还是比较完整的。本文篇幅有限,只是分析了部分的内核架构和实现。liteos-a内核麻雀虽小五脏俱全。基本的操作系统核心功能都有,并且代码写的很规范。只是函数名变量名为啥要用驼峰命名法,有种在写Java代码的感觉,一不小心写个class出来。后期liteos-a内核的开发应该着重在内核性能的优化,安全性的提高等方面。

    本文参与了「解读鸿蒙源码」技术征文,欢迎正在阅读的你也加入。

    展开全文
  • 此次鸿蒙OS的升级,不仅仅带来了分布式能力的全面提升,还为开发者提供了完整的分布式设备与应用开发生态,全面使能全场景智慧生态,共赢移动终端产业的下一个十年。最重要的是,鸿蒙OS 2.0面向应用开发者发布Beta...
  • 鸿蒙os2.0下载资源源代码发布 鸿蒙os2.0系统怎么样今日华为在 HDC 开发者大会上正式推出了鸿蒙 OS 2.0 系统,该系统今天面向大屏、手表、车机发布开发者 Beta 版,12 月发布手机版本,而明年华为智能手机将全面升级...
  • 最近,华为提出将其所有手机操作系统 在2020年12月份升级为鸿蒙OS2.0。那么,鸿蒙OS到底是啥东东呢?从目前公布的信息来看,面向手机的内核仍然采用的是Linux内核,面向物联网或其他终端设备采用LiteOS或传说中的...
  • 今年9月10号华为开发者大会中,华为正式开源发布了鸿蒙os 2.0系统,鸿蒙终于开放给开发者,目前只能用来做指挥屏/手表/车机。华为手机版本的鸿蒙系统则要到今年的12月才提供。在9月10号我就去鸿蒙gitee上的开源代码...
  • 鸿蒙os应用类型鸿蒙os应用分为以下三种:一、TV(电视机)电视机上的应用,前端页面开发可以使用js+hml+css作为界面开发语言。也可以使用xml来做开发(开发风格类似于安卓开发)。后端使用java二、Wearable(可穿戴设备)...
  • “本文面向的是开发人员,主要想通过科普让大家了解一下鸿蒙...换句话说,鸿蒙OS 是为全场景,分布式设计的,微内核,软总线是他重要的实现。对于全场景,分布式理解,我们可以想一下华为自家的多屏协作,以及电脑,...
  • 鸿蒙 OS 的到来,能为我们改变什么?

    万次阅读 多人点赞 2019-09-18 11:19:47
    作者 | 屠敏 出品 | CSDN(ID:CSDNnews) 「鸿蒙初辟原无姓,打破顽空需悟空」,在国产自研操作系统短缺的窘境之...作为一款基于微内核的全场景分布式 OS,「鸿蒙 OS」肩负打破传统 IoT 操作系统的责任,同时也成...
  • 鸿蒙OS开源代码精要解读之——init

    万次阅读 多人点赞 2020-09-25 09:34:26
    鸿蒙OS开源代码精要解读之——init 作者介绍: 中科创达OpenHarmony研究组 说明: 中科创达OpenHarmony研究组第一时间对https://codechina.csdn.net/openharmony上开源的代码进行了详尽的代码研读和学习。为此,...
  • “ 本文面向的是开发人员,主要想通过科普让大家了解一下鸿蒙开发。接下来,我想给大家科普一下这个这么火的鸿蒙...换句话说,鸿蒙OS 是为全场景,分布式设计的,微内核,软总线是他重要的实现。对于全场景,分布式...
  • 鸿蒙OS开源代码精要解读之——init作者介绍:中科创达...为此,我们打算编写一系列篇幅中等,内容精炼的源码分析文章来引领大家更进一步的走进鸿蒙OS。随着对代码的了解,广大开发者想亲自动手参与的意愿和信心也会...
  • 阅读本文大概需要 5 分钟。来自:51CTO技术栈作者:JackChen2020本文面向的是开发人员,主要想通过科普让大家了解一下鸿蒙开发。接下来,我想给大家科普一下这个这么火的鸿蒙系统。...换句话说,鸿蒙OS 是为全...
  • 作者1月22日消息荣耀今日...至于是否会使用鸿蒙 OS 系统,要看鸿蒙 OS 的开源进度,虽然荣耀脱胎于华为,但也会遵循业界的商业合作规则。作者了解到,鸿蒙 OS 是华为公司自研的操作系统,采用微内核分布式架构,于 ...
  • 原标题:大佬终于把鸿蒙OS讲明白了,收藏了! 到底什么是鸿蒙 OS在官网上看到鸿蒙 OS 的简介是,分布式能力造就新硬件、新交互、新服务,打开焕然一新的全场景世界。以及发布会提及最多是他的万物互连,全场景,...
  • 鸿蒙 OS 2.0 来了!值得开发者关注的是什么?

    万次阅读 多人点赞 2020-09-10 16:56:26
    鸿蒙 OS 首发时,余承东特意用橙色标明 1.0 版本「基于开源框架,关键模块自研」。而按照华为的规划,今年在 HDC 上刚刚发布的鸿蒙 2.0 迎来了史诗级升级,完全演化成一个自主独立的操作系统。
  • 一 概述作为鸿蒙OS应用开发的初学者,本篇介绍开发工具的安装与配置准备工作软件的下载与安装配置开发环境第一个程序(Hello World)二 准备2.1 开发工具Java:编译构建依赖JDK(版本>=1.8)Node.js:应用于开发JS...
  • 项目背景 本项目是CSDN在编辑部协同IT领域具有技术影响力的知名企业和专家,共同打造的13个当前热门技术领域的技术知识点及相关学习资源,最终CSDN编辑进行了编辑汇总,最终制作成13张知识图谱及成长路线。...
  • 鸿蒙OS下载地址

    万次阅读 多人点赞 2019-08-10 17:27:44
    奈何很多人不知道,鸿蒙OS的下载地址,随便写一点发个官网链接。 鸿蒙系统是基于微内核的全场景分布式OS,可按需扩展,实现更广泛的系统安全,主要用于物联网,特点是低时延,甚至可到毫秒级乃至亚毫秒级...
  • 本文将首先带您回顾“系统调用”的概念以及它的作用,然后从经典的Hello World开始,逐行代码层层分析——鸿蒙OS的系统调用是如何实现的。写在前面9月10号 华为开发者大会(HDC)上,华为向广大开发者宣布了鸿蒙2.0...
  • 来自 | GitHub科技本文面向的是开发人员,主要想通过科普让大家了解一下鸿蒙开发。接下来,我想给大家科普一下这个这么火的鸿蒙...换句话说,鸿蒙OS 是为全场景,分布式设计的,微内核,软总线是他重要的实现。C/C...
  • 华为鸿蒙OS之HelloWorld

    千次阅读 多人点赞 2020-09-13 19:01:53
    华为鸿蒙OS之HelloWorld 这两天很火的一个话题华为鸿蒙OS2.0发布了。个人开发者也可以进行鸿蒙OS的应用或者硬件开发。作为一个“啥也不会的程序员”,时刻要保持着学习的心态,所以本文将会介绍基于鸿蒙OS的应用开发...
  • 来自 | GitHub科技本文面向的是开发人员,主要想通过科普让大家了解一下鸿蒙开发。接下来,我想给大家科普一下这个这么火的...换句话说,鸿蒙OS 是为全场景,分布式设计的,微内核,软总线是他重要的实现。对于全...
  • 鸿蒙OS源码

    万次阅读 2019-09-01 00:00:06
    鸿蒙OS操作系统一声巨响,横空出世 首先附上源码链接 鸿蒙 鸿蒙系统(HarmonyOS)是基于微内核的全场景分布式OS,可按需扩展,实现更广泛的系统安全,主要用于物联网,特点是低时延,甚至可到毫秒级乃至亚毫秒级。 ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,660
精华内容 1,064
关键字:

鸿蒙os