gkxg001的博客

为了验证下openharmony中对文件的操作和原始的linux有没有什么区别，发现默认的镜像中没有编译文件的工具(例如vi、Nano等)，所以从[网上找了个比较早期的vi工具的源码，进行部署验证。

如下命令查看进程信息，为了简化说明此处只留下了一个最具有代表性的进程进行说明

在 Linux 系统中，**nice值**是一个用于调整进程优先级的参数。它允许用户或系统管理员控制进程占用 CPU 时间的比例。nice值的范围是从 `-20` 到 `19`，默认值是 `0`。以下是 nice 值的具体含义和作用

本应用程序(led_rgb)是在上实现直接**通过消息机制与内核驱动进行交互，设置RGB三色灯的亮灯行为**。我从网上随便找了个demo测试了一下，坑了三天......，整个状态如下图，同时也迫使我深度梳理了一下整个流程框架。直到绝望的时候，翻书找思路的时候**找到了答案**。。。最绝的是想分享的时候从码云上找了下原作者的demo，发现**人家有相关问题的说明**。实际经验分享完毕，下面开始说细节

OpenHarmony 中，组网模块（bus_center）和发现模块（discovery）傻傻分不清楚

好久之前在测试openharmony的开发板时使用过hdc工具，印象中是比较顺利，所以也没有做相关的记录，但今天想传个文件，由于系统中没有自带ssh等网络协议，所以就想用hdc直接传一下，但死活没通过，半天后尝试换了下终端

每次用这个工具hilog都有一些小用法记不清，需要花一些时间去查去分析使用方法，为了给丰富多彩的生活留出更多的时间，所以汇总整理共享来了。它来了它来了~~~~~~~~~开始是想通过3.1来汇总的，但实际测试发现openharmony3.1和openharmony5.0的区别还是比较大的，所以中间又采用的5.0的版本，又使用3.1版本的可以查看附件的简单说明。

要想大概了解一个公司，我们可能只需要知道它的运行逻辑即可，例如我们只需要知道它有财务有研发有运营等，财务报销、研发负责产品等即可，但是如果想深入具体的了解的话我们就要了解都有什么部门(对象)、各部门都包含哪些职责(对象方法)以及各部门都包含哪些关键人员(子对象)以及他们的职责(子对象方法)，根据这个逻辑我大概整理了openharmony 5.0的HDF框架中包含的关键对象以及对应的方法，便于更深的理解HDF的实现。

要想大概了解一个公司，我们可能只需要知道它的运行逻辑即可，例如我们只需要知道它有财务有研发有运营等，财务报销、研发负责产品等即可，但是如果想深入具体的了解的话我们就要了解都有什么部门(对象)、各部门都包含哪些职责(对象方法)以及各部门都包含哪些关键人员(子对象)以及他们的职责(子对象方法)，根据这个逻辑我大概整理了HDF框架中包含的关键对象以及对应的方法，便于更深的理解HDF的实现

本文将深入分析 OpenHarmony 5.0 中分布式软总线的实现原理，包括其架构设计、核心功能、实现机制以及实际应用。(**只包含了软总线的一些核心内容，对于整体的框架还在整理中，例如分布式数据如何管理的、分布式的任务调度等等好多东西还没理清楚**)

HDF框架提供统一的驱动消息机制，支持用户态应用向内核态驱动发送消息，也支持内核态驱动向用户态应用发送消息，用于当用户态应用和内核态驱动需要交互的场景。

在分析openharmony 5.0的HDF驱动框架时我们会发现用了很多面向对象的思想，例如类继承、接口、单例类等，本来应该是好事情，但使用时对象之间的关系交错复杂，不太符合linux内核分层分模块的思路，导致整体理解起来比较困难，再加上"C/S设计模式”和“观察者设计模式"更导致系统理解起来比较麻烦，本文便针对观察者模式这个问题做梳理

在分析openharmony的hdf框架的设备驱动加载器(IDriverLoader)时发现在创建实例时会首先判断一下是否完成了驱动入口的构建(HdfDriverEntryConstruct)，如果没有构建会重新构建，这与我开始以为的不一致(我一直以为是采用的linux内核方式，只是由hdf来将驱动注册进去)，oh将这部分由hdf框架接管了。下面我便将这部分实现驱动程序的动态加载和管理的技术细节进行分析

在看openharmony源码时发现和其他开源linux的比较大的区别是实现了多平台的支持和一些系统组件，而且是统一构建的，在做一些更改时也只能参考一些已有的文章，但稍微有点特殊的需求，便有点心虚不知如何下手了，尤其是编译构建的相关的问题，所以有了这篇源码剖析记录。编译构建框架以gn+ninja作为基础构建系统，(不熟悉gn和ninja的可以参考这篇文章,大概了解下)，针对产品需要和部件化功能，在gn阶段前增加了preloader和loader的预加载过程。preloader: 产品信息预加载。

openharmony编译过程(python)中如何实现在配置文件中配置相关的实现函数的

设备节点（HdfDeviceNode）和 设备实例（HdfDevice）是两个重要的概念，而且非常容易混淆，它们在设备管理和驱动加载过程中扮演不同的角色。以下是它们的区别和联系

在分析openharmony的HDF驱动框架时我们会发现用了很多面向对象的思想，例如类继承、接口、单例类等，本来应该是好事情，但使用时对象之间的关系交错复杂，不太符合linux内核分层分模块的思路，导致整体理解起来比较困难，再加上"C/S设计模式”和“观察者设计模式"更导致系统理解起来比较麻烦，本文便针对C/S设计模式和单例类这个问题做梳理。

备注方式是优先参考的源码中的说明文档，有一些不太了解，也只是按自己的理解写的，梳理了下开源鸿蒙系统(5.0版本)中大概都包含哪些东西，通过对。

openharmony中hdfSRef结构:一个基于引用计数的智能引用管理功能，通常用于管理资源的生命周期，确保资源在不再被使用时被正确释放

宏是一种在C语言中常用的技巧，用于通过结构体中的某个成员指针反向推导出该结构体本身的指针。这个宏非常有用，尤其是在处理链表、树等数据结构时，当我们只有某个节点的某个成员变量的指针时，可以通过这个宏获取到该节点的完整结构体指针。宏通过计算结构体成员相对于结构体起始地址的偏移量，然后从成员指针中减去这个偏移量，从而得到结构体的起始地址。这是一种非常巧妙的技术，可以在不直接持有结构体指针的情况下，通过结构体中的某个成员指针来获取整个结构体的指针。结构体的指针，并允许我们通过这个指针访问结构体的其他成员。

根据gn工程中的快速入门GN Quick Start guide做了个简单的实操，并做了下记录

在阅读openharmony的hdf框架中发现在DeviceTokenClnt、HdfHostInfo、HdfDeviceInfo等结构体中以node成员变量(struct HdfSListNode node)为开头，开始不明白具体含义，后经梳理业务明白它是用来实现动态管理信息(在系统启动或运行时对进行添加、删除和遍历操作)，具体实现的技术细节不复杂，和linux内核的contaner_of函数类似，但是在hdf中出现的频次实在是有点高了，所以想着还是单独拎出来举个例子增强一下理解。