@hmos-library-adapter/fast 0.0.17-beta.1 → 0.0.17-beta.2

package/node_modules/@ohos-agent/pc-adapter/skills/openharmony-device-porting/references-full/kernel/kernel-overview.md

@@ -0,0 +1,177 @@
+# 内核概述
+
+
+### 内核简介
+
+用户最常见到并与之交互的操作系统界面，其实只是操作系统最外面的一层。操作系统最重要的任务，包括管理硬件设备，分配系统资源等，我们称之为操作系统内在最重要的核心功能。而实现这些核心功能的操作系统模块，业界一般称之为操作系统“内核”。
+
+
+### 实现原理
+
+操作系统是位于应用和硬件之间的系统软件，向上提供易用的程序接口和运行环境，向下管理硬件资源。内核位于操作系统的下层，为操作系统上层的程序框架提供硬件资源的并发管理。
+
+  **图1** 操作系统架构 
+ 
+  ![zh-cn_image_0000001388170721](figures/zh-cn_image_0000001388170721.png)
+
+
+### 多内核架构和基本组成
+
+业界的内核有很多，但无论是什么内核，基本上有几个最重要的组成单元是每个内核均要具备的，分别是：
+
+- 负责持久化数据，并让应用程序能够方便的访问持久化数据的“文件系统”。
+
+- 负责管理进程地址空间的“内存管理”。
+
+- 负责管理多个进程的“进程管理”或者“任务管理“。
+
+- 负责本机操作系统和另外一个设备上操作系统通信的“网络”。
+
+OpenHarmony采用了多内核结构，支持Linux和LiteOS，开发者可按不同产品规格进行选择使用。Linux和LiteOS均具备上述组成单元，只是实现方式有所不同。多个内核通过KAL（Kernel Abstraction Layer）模块，向上提供统一的标准接口。
+
+内核子系统位于OpenHarmony下层。需要特别注意的是，由于OpenHarmony面向多种设备类型，这些设备有着不同的CPU能力，存储大小等。为了更好的适配这些不同的设备类型，内核子系统支持针对不同资源等级的设备选用适合的OS内核，内核抽象层（KAL，Kernel Abstract Layer）通过屏蔽内核间差异，对上层提供基础的内核能力。
+
+  **图2** OpenHarmony架构图 
+
+ 
+  ![1_zh-cn_image_0000001128794202](figures/1_zh-cn_image_0000001128794202.png)
+
+
+### 不同内核适配的系统及设备类型
+
+OpenHarmony按照支持的设备可分为如下几种系统类型：
+
+- 轻量系统（mini system）
+  面向MCU类处理器例如Arm Cortex-M、RISC-V 32位的设备，硬件资源极其有限，支持的设备最小内存为128KiB，可以提供多种轻量级网络协议，轻量级的图形框架，以及丰富的IOT总线读写部件等。可支撑的产品如智能家居领域的连接类模组、传感器设备、穿戴类设备等。
+
+- 小型系统（small system）
+  面向应用处理器例如Arm Cortex-A的设备，支持的设备最小内存为1MiB，可以提供更高的安全能力、标准的图形框架、视频编解码的多媒体能力。可支撑的产品如智能家居领域的IP Camera、电子猫眼、路由器以及智慧出行域的行车记录仪等。
+
+- 标准系统（standard system）
+  面向应用处理器例如Arm Cortex-A的设备，支持的设备最小内存为128MiB，可以提供增强的交互能力、3D GPU以及硬件合成能力、更多控件以及动效更丰富的图形能力、完整的应用框架。可支撑的产品如高端的冰箱显示屏。
+
+OpenHarmony针对不同量级的系统，使用了不同形态的内核。轻量系统、小型系统可以选用LiteOS；小型系统和标准系统可以选用Linux。其对应关系如下表：
+
+  **表1** 系统关系对应表
+
+| 系统级别 | 轻量系统 | 小型系统 | 标准系统 | 
+| -------- | -------- | -------- | -------- |
+| LiteOS-M | √ | × | × | 
+| LiteOS-A | × | √ | × | 
+| Linux | × | √ | √ | 
+
+
+## LiteOS-M
+
+
+### 内核架构
+
+OpenHarmony LiteOS-M内核是面向IoT领域构建的轻量级物联网操作系统内核，具有小体积、低功耗、高性能的特点，其代码结构简单，主要包括内核最小功能集、内核抽象层、可选组件以及工程目录等，分为硬件相关层以及硬件无关层，硬件相关层提供统一的HAL（Hardware Abstraction Layer）接口，提升硬件易适配性，不同编译工具链和芯片架构的组合分类，满足AIoT类型丰富的硬件和编译工具链的拓展。
+
+  **图3** LiteOS-M架构图  
+
+  ![内核](figures/内核.png)
+
+
+### 使用指导
+
+LiteOS-M使用指导请参见LiteOS-M[内核概述](kernel-mini-overview.md)的“使用说明”章节。
+
+
+## LiteOS-A
+
+
+### 内核架构
+
+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等。
+
+为适应IoT产业的高速发展，OpenHarmony 轻量级内核不断优化和扩展，能够带给开发者友好的开发体验和统一开放的生态系统能力。轻量级内核LiteOS-A重要的新特性如下：
+
+- 新增了丰富的内核机制：
+  - 新增虚拟内存、系统调用、多核、轻量级IPC（Inter-Process Communication，进程间通信）、DAC（Discretionary Access Control，自主访问控制）等机制，丰富了内核能力；
+  - 为了更好的兼容软件和开发者体验，新增支持多进程，使得应用之间内存隔离、相互不影响，提升系统的健壮性。
+
+- 引入统一驱动框架HDF（Hardware Driver Foundation）
+
+  引入统一驱动框架HDF，统一驱动标准，为设备厂商提供了更统一的接入方式，使驱动更加容易移植，力求做到一次开发，多系统部署。
+
+- 支持1200+标准POSIX接口
+
+  更加全面的支持POSIX标准接口，使得应用软件易于开发和移植，给应用开发者提供了更友好的开发体验。
+
+- 内核和硬件高解耦
+
+  轻量级内核与硬件高度解耦，新增单板，内核代码不用修改。
+
+  **图4** OpenHarmony LiteOS-A内核架构图 
+
+  ![1661308214897](figures/1661308214897.png)
+
+
+### 使用指导
+
+LiteOS-A使用指导请参见LiteOS-A[内核概述](kernel-small-overview.md)的“使用说明”章节。
+
+
+## Linux
+
+
+### linux内核概述
+
+OpenHarmony的Linux内核基于开源Linux内核LTS **4.19.y / 5.10.y** 分支演进，在此基线基础上，回合CVE补丁及OpenHarmony特性，作为OpenHarmony Common Kernel基线。针对不同的芯片，各厂商合入对应的板级驱动补丁，完成对OpenHarmony的基线适配。
+
+- Linux社区LTS 4.19.y分支信息请查看[kernel官网](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-4.19.y)。
+
+- Linux社区LTS 5.10.y分支信息请查看[kernel官网](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-5.10.y)。
+
+内核的Patch组成模块，在编译构建流程中，针对具体芯片平台，合入对应的架构驱动代码，进行编译对应的内核镜像。所有补丁来源均遵守GPL-2.0协议。
+
+
+### 内核增强特性
+
+OpenHarmony针对linux内核在ESwap(Enhanced Swap)、关联线程组调度和CPU轻量级隔离做了增强。
+
+**Enhanced SWAP特性**
+
+ESwap提供了自定义新增存储分区作为内存交换分区的能力，并创建了一个常驻进程zswapd将[ZRAM](https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html)压缩后的匿名页加密换出到ESwap存储分区，从而能完全的空出一块可用内存，以此来达到维持Memavailable水线的目标。同时，配合这个回收机制，在整个内存框架上进行改进，优化匿名页和文件页的回收效率，并且使两者的回收比例更加合理以避免过度回收导致的refault问题造成卡顿现象。
+
+**关联线程组调度**
+
+关联线程组(related thread group)提供了对一组关键线程调度优化的能力，支持对关键线程组单独进行负载统计和预测，并且设置优选CPU cluster功能，从而达到为组内线程选择最优CPU运行并且根据分组负载选择合适的CPU调频点运行。
+
+**CPU轻量级隔离**
+
+CPU轻量级隔离特性提供了根据系统负载和用户配置来选择合适的CPU进行动态隔离的能力。内核会将被隔离CPU上的任务和中断迁移到其他合适的CPU上执行，被隔离的CPU会进入ilde状态，以此来达到功耗优化的目标。同时提供用户态的配置和查询接口来实现更好的系统调优。
+
+
+### 使用指导
+
+1. 合入HDF补丁
+     在kernel/linux/build仓中，按照kernel.mk中HDF的补丁合入方法，合入不同内核版本对应的HDF内核补丁：
+     
+   ```
+   $(OHOS_BUILD_HOME)/drivers/hdf_core/adapter/khdf/linux/patch_hdf.sh $(OHOS_BUILD_HOME) $(KERNEL_SRC_TMP_PATH) $(KERNEL_PATCH_PATH) $(DEVICE_NAME)
+   ```
+
+2. 合入芯片平台驱动补丁
+   以Hi3516DV300为例：
+
+     在kernel/linux/build仓中，按照kernel.mk中的芯片组件所对应的patch路径规则及命名规则，将对应的芯片组件patch放到对应路径下：
+     
+   ```
+   DEVICE_PATCH_DIR := $(OHOS_BUILD_HOME)/kernel/linux/patches/${KERNEL_VERSION}/$(DEVICE_NAME)_patch
+   DEVICE_PATCH_FILE := $(DEVICE_PATCH_DIR)/$(DEVICE_NAME).patch
+   ```
+
+3. 修改自己所需要编译的config
+     在kernel/linux/build仓中，按照kernel.mk中的芯片组件所对应的patch路径规则及命名规则，将对应的芯片组件config放到对应路径下：
+     
+   ```
+   KERNEL_CONFIG_PATH := $(OHOS_BUILD_HOME)/kernel/linux/config/${KERNEL_VERSION}DEFCONFIG_FILE := $(DEVICE_NAME)_$(BUILD_TYPE)_defconfig
+   ```
+
+   > ![icon-notice.gif](public_sys-resources/icon-notice.gif) **须知：**
+   > 由于OpenHarmony工程的编译构建流程中会拷贝kernel/linux/linux-\*.\*的代码环境后进行打补丁动作，在使用OpenHarmony的版本级编译命令前，需要kernel/linux/linux-\*.\*原代码环境。
+   > 
+   > 根据不同系统工程，编译完成后会在out目录下的kernel目录中生成对应实际编译的内核，基于此目录的内核，进行对应的config修改，将最后生成的.config文件cp到config仓对应的路径文件里，即可生效。
+

package/node_modules/@ohos-agent/pc-adapter/skills/openharmony-device-porting/references-full/kernel/kernel-small-apx-dll.md

@@ -0,0 +1,124 @@
+# 双向链表
+
+
+## 基本概念
+
+双向链表是指含有往前和往后两个方向的链表，即每个结点中除存放下一个节点指针外，还增加一个指向前一个节点的指针。其头指针head是唯一确定的。从双向链表中的任意一个结点开始，都可以很方便地访问它的前驱结点和后继结点，这种数据结构形式使得双向链表在查找时更加方便，特别是大量数据的遍历。由于双向链表具有对称性，能方便地完成各种插入、删除等操作，但需要注意前后方向的操作。
+
+
+## 功能说明
+
+双向链表模块为用户提供下面几种功能，接口详细信息可以查看[API参考](https://gitcode.com/openharmony/kernel_liteos_m/blob/master/utils/los_list.h)。
+
+  | | |
+| -------- | -------- |
+| **功能分类** | **接口名** | 
+| 初始化链表 | -&nbsp;LOS_ListInit：将指定节点初始化为双向链表节点。<br/>-&nbsp;LOS_DL_LIST_HEAD：定义一个节点并初始化为双向链表节点。 | 
+| 增加节点 | -&nbsp;LOS_ListAdd：将指定节点插入到双向链表头端。<br/>-&nbsp;LOS_ListHeadInsert：将指定节点插入到双向链表头端，同LOS_ListAdd。<br/>-&nbsp;LOS_ListTailInsert：将指定节点插入到双向链表尾端。 | 
+| 增加链表 | -&nbsp;LOS_ListAddList：将指定链表的头端插入到双向链表头端。<br/>-&nbsp;LOS_ListHeadInsertList：将指定链表的头端插入到双向链表头端。<br/>-&nbsp;LOS_ListTailInsertList：将指定链表的尾端插入到双向链表头端。 | 
+| 删除节点 | -&nbsp;LOS_ListDelete：将指定节点从链表中删除。<br/>-&nbsp;LOS_ListDelInit：将指定节点从链表中删除，并使用该节点初始化链表。 | 
+| 判断双向链表 | -&nbsp;LOS_ListEmpty：判断链表是否为空。<br/>-&nbsp;LOS_DL_LIST_IS_END：判断指定链表节点是否为链表尾端。<br/>-&nbsp;LOS_DL_LIST_IS_ON_QUEUE：判断链表节点是否在双向链表里。 | 
+| 获取结构体信息 | -&nbsp;LOS_OFF_SET_OF：获取指定结构体内的成员相对于结构体起始地址的偏移量。<br/>-&nbsp;LOS_DL_LIST_ENTRY：获取双向链表中第一个链表节点所在的结构体地址，接口的第一个入参表示的是链表中的头节点，第二个入参是要获取的结构体名称，第三个入参是链表在该结构体中的名称<br/>-&nbsp;LOS_ListPeekHeadType：获取双向链表中第一个链表节点所在的结构体地址，接口的第一个入参表示的是链表中的头节点，第二个入参是要获取的结构体名称，第三个入参是链表在该结构体中的名称。如果链表为空，返回NULL。<br/>-&nbsp;LOS_ListRemoveHeadType：获取双向链表中第一个链表节点所在的结构体地址，并把第一个链表节点从链表中删除。接口的第一个入参表示的是链表中的头节点，第二个入参是要获取的结构体名称，第三个入参是链表在该结构体中的名称。如果链表为空，返回NULL。<br/>-&nbsp;LOS_ListNextType：获取双向链表中指定链表节点的下一个节点所在的结构体地址。接口的第一个入参表示的是链表中的头节点，第二个入参是指定的链表节点，第三个入参是要获取的结构体名称，第四个入参是链表在该结构体中的名称。如果链表节点下一个为链表头结点为空，返回NULL。| 
+| 遍历双向链表 | -&nbsp;LOS_DL_LIST_FOR_EACH：遍历双向链表。<br/>-&nbsp;LOS_DL_LIST_FOR_EACH_SAFE：遍历双向链表，并存储当前节点的后继节点用于安全校验。 | 
+| 遍历包含双向链表的结构体 | -&nbsp;LOS_DL_LIST_FOR_EACH_ENTRY：遍历指定双向链表，获取包含该链表节点的结构体地址。<br/>-&nbsp;LOS_DL_LIST_FOR_EACH_ENTRY_SAFE：遍历指定双向链表，获取包含该链表节点的结构体地址，并存储包含当前节点的后继节点的结构体地址。 | 
+
+
+## 开发流程
+
+双向链表的典型开发流程：
+
+1. 调用LOS_ListInit/LOS_DL_LIST_HEAD初始双向链表。
+
+2. 调用LOS_ListAdd向链表插入节点。
+
+3. 调用LOS_ListTailInsert向链表尾部插入节点。
+
+4. 调用LOS_ListDelete删除指定节点。
+
+5. 调用LOS_ListEmpty判断链表是否为空。
+
+6. 调用LOS_ListDelInit删除指定节点并以此节点初始化链表。
+
+
+> ![icon-note.gif](public_sys-resources/icon-note.gif) **说明：**
+> - 需要注意节点指针前后方向的操作。
+> 
+> - 链表操作接口，为底层接口，不对入参进行判空，需要使用者确保传参合法。
+> 
+> - 如果链表节点的内存是动态申请的，删除节点时，要注意释放内存。
+
+
+## 编程实例 
+
+
+###  实例描述
+
+本实例实现如下功能：
+
+
+1. 初始化双向链表。
+
+2. 增加节点。
+
+3. 删除节点。
+
+4. 测试操作是否成功。
+
+### 编程示例
+
+本演示代码在./kernel/liteos_a/testsuites/kernel/src/osTest.c中编译验证，在TestTaskEntry中调用验证入口函数ListSample
+
+示例代码如下：
+  
+```
+#include "stdio.h"
+#include "los_list.h"
+
+static UINT32 ListSample(VOID)
+{
+    LOS_DL_LIST listHead = {NULL,NULL};
+    LOS_DL_LIST listNode1 = {NULL,NULL};
+    LOS_DL_LIST listNode2 = {NULL,NULL};
+
+    //首先初始化链表
+    PRINTK("Initial head\n");
+    LOS_ListInit(&listHead);
+
+    //添加节点1和节点2，并校验他们的相互关系
+    LOS_ListAdd(&listHead, &listNode1);
+    if (listNode1.pstNext == &listHead && listNode1.pstPrev == &listHead) {
+        PRINTK("Add listNode1 success\n");
+    }
+
+    LOS_ListTailInsert(&listHead, &listNode2);
+    if (listNode2.pstNext == &listHead && listNode2.pstPrev == &listNode1) {
+        PRINTK("Tail insert listNode2 success\n");
+    }
+
+    //删除两个节点
+    LOS_ListDelete(&listNode1);
+    LOS_ListDelete(&listNode2);
+
+    //确认链表为空
+    if (LOS_ListEmpty(&listHead)) {
+        PRINTK("Delete success\n");
+    }
+
+    return LOS_OK;
+}
+```
+
+
+**结果验证**
+
+
+编译运行得到的结果为：
+
+
+  
+```
+Initial head 
+Add listNode1 success 
+Tail insert listNode2 success
+Delete success
+```

package/node_modules/@ohos-agent/pc-adapter/skills/openharmony-device-porting/references-full/kernel/kernel-small-apx-library.md

@@ -0,0 +1,285 @@
+# 标准库
+
+
+OpenHarmony内核使用[musl libc库](../../application-dev/reference/native-lib/musl.md)，支持标准POSIX接口，开发者可基于POSIX标准接口开发内核之上的组件及应用。
+
+
+## 标准库接口框架
+
+  **图1** POSIX接口框架
+
+  ![zh-cn_image_0000001172904117](figures/zh-cn_image_0000001172904117.png)
+
+musl libc库支持POSIX标准，涉及的系统调用相关接口由OpenHarmony内核适配支持 ，以满足接口对外描述的功能要求。
+
+标准库支持接口的详细情况请参考[C库的API文档](../../application-dev/reference/native-lib/musl.md)，其中也涵盖了与POSIX标准之间的差异说明。
+
+
+### 编程实例
+
+
+####  实例描述
+
+在本示例中，主线程创建了THREAD_NUM个子线程，每个子线程启动后等待被主线程唤醒，主线程成功唤醒所有子线程后，子线程继续执行直至生命周期结束，同时主线程通过pthread_join方法等待所有线程执行结束。
+
+####  编程示例
+
+本演示代码在./kernel/liteos_a/testsuites/kernel/src/osTest.c中编译验证，在TestTaskEntry中调用验证入口函数ExamplePosix。
+
+示例代码如下：  
+
+```
+#include <stdio.h>
+#include <unistd.h>
+#include <pthread.h>
+
+#define THREAD_NUM 3
+int g_startNum = 0; /* 启动的线程数 */
+int g_wakenNum = 0; /* 唤醒的线程数 */
+
+struct testdata {
+    pthread_mutex_t mutex;
+    pthread_cond_t cond;
+} g_td;
+
+/* 子线程入口函数 */
+static VOID *ChildThreadFunc(VOID *arg)
+{
+    int rc;
+    pthread_t self = pthread_self();
+
+    /* 获取mutex锁 */
+    rc = pthread_mutex_lock(&g_td.mutex);
+    if (rc != 0) {
+        dprintf("ERROR:take mutex lock failed, error code is %d!\n", rc);
+        goto EXIT;
+    }
+
+    /* g_startNum计数加一，用于统计已经获得mutex锁的子线程个数 */
+    g_startNum++;
+
+    /* 等待cond条件变量 */
+    rc = pthread_cond_wait(&g_td.cond, &g_td.mutex);
+    if (rc != 0) {
+        dprintf("ERROR: pthread condition wait failed, error code is %d!\n", rc);
+        (void)pthread_mutex_unlock(&g_td.mutex);
+        goto EXIT;
+    }
+
+    /* 尝试获取mutex锁，正常场景，此处无法获取锁 */
+    rc = pthread_mutex_trylock(&g_td.mutex);
+    if (rc == 0) {
+        dprintf("ERROR: mutex gets an abnormal lock!\n");
+        goto EXIT;
+    }
+
+    /* g_wakenNum计数加一，用于统计已经被cond条件变量唤醒的子线程个数 */
+    g_wakenNum++;
+
+    /* 释放mutex锁 */
+    rc = pthread_mutex_unlock(&g_td.mutex);
+    if (rc != 0) {
+        dprintf("ERROR: mutex release failed, error code is %d!\n", rc);
+        goto EXIT;
+    }
+EXIT:
+    return NULL;
+}
+
+static int ExamplePosix(VOID)
+{
+    int i, rc;
+    pthread_t thread[THREAD_NUM];
+
+    /* 初始化mutex锁 */
+    rc = pthread_mutex_init(&g_td.mutex, NULL);
+    if (rc != 0) {
+        dprintf("ERROR: mutex init failed, error code is %d!\n", rc);
+        goto ERROROUT;
+    }
+
+    /* 初始化cond条件变量 */
+    rc = pthread_cond_init(&g_td.cond, NULL);
+    if (rc != 0) {
+        dprintf("ERROR: pthread condition init failed, error code is %d!\n", rc);
+        goto ERROROUT;
+    }
+
+    /* 批量创建THREAD_NUM个子线程 */
+    for (i = 0; i < THREAD_NUM; i++) {
+        rc = pthread_create(&thread[i], NULL, ChildThreadFunc, NULL);
+        if (rc != 0) {
+            dprintf("ERROR: pthread create failed, error code is %d!\n", rc);
+            goto ERROROUT;
+        }
+    }
+    dprintf("pthread_create ok\n");
+
+    /* 等待所有子线程都完成mutex锁的获取 */
+    while (g_startNum < THREAD_NUM) {
+        usleep(100);
+    }
+
+    /* 获取mutex锁，确保所有子线程都阻塞在pthread_cond_wait上 */
+    rc = pthread_mutex_lock(&g_td.mutex);
+    if (rc != 0) {
+        dprintf("ERROR: mutex lock failed, error code is %d\n", rc);
+        goto ERROROUT;
+    }
+
+    /* 释放mutex锁 */
+    rc = pthread_mutex_unlock(&g_td.mutex);
+    if (rc != 0) {
+        dprintf("ERROR: mutex unlock failed, error code is %d!\n", rc);
+        goto ERROROUT;
+    }
+
+    for (int j = 0; j < THREAD_NUM; j++) {
+        /* 在cond条件变量上广播信号 */
+        rc = pthread_cond_signal(&g_td.cond);
+        if (rc != 0) {
+            dprintf("ERROR: pthread condition failed, error code is %d!\n", rc);
+            goto ERROROUT;
+        }
+    }
+
+    sleep(1);
+
+    /* 检查是否所有子线程都已被唤醒 */
+    if (g_wakenNum != THREAD_NUM) {
+        dprintf("ERROR: not all threads awaken, only %d thread(s) awaken!\n", g_wakenNum);
+        goto ERROROUT;
+    }
+    dprintf("all threads awaked\n");
+
+    /* join所有子线程，即等待其结束 */
+    for (i = 0; i < THREAD_NUM; i++) {
+        rc = pthread_join(thread[i], NULL);
+        if (rc != 0) {
+            dprintf("ERROR: pthread join failed, error code is %d!\n", rc);
+            goto ERROROUT;
+        }
+    }
+    dprintf("all threads join ok\n");
+
+    /* 销毁cond条件变量 */
+    rc = pthread_cond_destroy(&g_td.cond);
+    if (rc != 0) {
+        dprintf("ERROR: pthread condition destroy failed, error code is %d!\n", rc);
+        goto ERROROUT;
+    }
+    return 0;
+ERROROUT:
+    return -1;
+}
+```
+
+#### 验证结果
+
+  输出结果如下：
+
+```
+pthread_create ok
+all threads awaked
+all threads join ok
+```
+
+## 与Linux标准库差异
+
+本节描述了OpenHarmony内核承载的标准库与Linux标准库之间存在的关键差异。更多差异详见C库API文档说明。
+
+
+### 进程
+
+1. OpenHarmony用户态**进程**优先级只支持静态优先级且用户态可配置的优先级范围为10(最高优先级)-31(最低优先级）。
+
+2. OpenHarmony用户态**线程**优先级只支持静态优先级且用户态可配置的优先级范围为0(最高优先级)-31(最低优先级）。
+
+3. OpenHarmony进程调度策略只支持SCHED_RR， 线程调度策略支持SCHED_RR和SCHED_FIFO。
+
+
+### 内存
+
+**与Linux mmap的差异**
+
+mmap接口原型为：void \*mmap (void \*addr, size_t length, int prot, int flags, int fd, off_t offset)。
+
+其中，参数fd的生命周期实现与Linux glibc存在差异。具体体现在，glibc在成功调用mmap进行映射后，可以立即释放fd句柄。在OpenHarmony内核中，不允许用户在映射成功后立即关闭相关fd，只允许在取消映射munmap后再进行fd的close操作。如果用户不进行fd的close操作，操作系统将在进程退出时对该fd进行回收。
+
+**代码举例**
+
+
+Linux目前支持的情况如下：
+
+```
+int main(int argc, char *argv[])
+{
+    int fd;
+    void *addr = NULL;
+    ...
+    fd = open(argv[1], O_RDONLY);
+    if (fd == -1){
+        perror("open");
+        exit(EXIT_FAILURE);
+    }
+    addr = mmap(NULL, length, PROT_READ, MAP_PRIVATE, fd, offset);
+    if (addr == MAP_FAILED) {
+        perror("mmap");
+        exit(EXIT_FAILURE);
+    }
+    close(fd);  /* OpenHarmony does not support closing fd immediately after the mapping is successful. */ 
+    ...
+    exit(EXIT_SUCCESS);
+}
+```
+
+
+  OpenHarmony支持的情况如下：
+
+```
+int main(int argc, char *argv[])
+{
+    int fd;
+    void *addr = NULL;
+    ...
+    fd = open(argv[1], O_RDONLY);
+    if (fd == -1) {
+        perror("open");
+        exit(EXIT_FAILURE);
+    }
+    addr = mmap(NULL, length, PROT_READ, MAP_PRIVATE, fd, offset);
+    if (addr == MAP_FAILED) {
+        perror("mmap");
+        exit(EXIT_FAILURE);
+    }
+    ...
+    munmap(addr, length);
+    close(fd);  /* Close fd after the munmap is canceled. */
+    exit(EXIT_SUCCESS);
+}
+```
+
+
+### 文件系统
+
+**系统目录**：用户无权限修改系统目录和设备挂载目录。包含/dev，/proc，/app，/bin，/data，/etc，/lib，/system，/usr目录。
+
+**用户目录**：用户可以在该目录下进行文件创建、读写，但**不能进行设备挂载**。用户目录指/storage目录。
+
+除**系统目录**与**用户目录**之外，用户可以自行创建文件夹进行设备的挂载。但是要注意，已挂载的文件夹及其子文件夹不允许重复或者嵌套挂载，非空文件夹不允许挂载。
+
+
+### 信号
+
+- 信号默认行为不支持STOP、CONTINUE、COREDUMP功能。
+
+- 无法通过信号唤醒正在睡眠状态（举例：进程调用sleep函数进入睡眠）的进程。原因：信号机制无唤醒功能，当且仅当进程被CPU调度运行时才能处理信号内容。
+
+- 进程退出后会发送SIGCHLD给父进程，发送动作无法取消。
+
+- 信号仅支持1-30号信号，接收方收到多次同一信号，仅执行一次回调函数。
+
+
+### Time
+
+OpenHarmony当前时间精度以tick计算，系统默认10ms/tick。sleep、timeout系列函数时间误差&lt;=20ms。

package/node_modules/@ohos-agent/pc-adapter/skills/openharmony-device-porting/references-full/kernel/kernel-standard-build.md

@@ -0,0 +1,18 @@
+# Linux内核编译与构建指导
+
+
+ **开发示例** 
+
+以rk3568开源开发板+ubuntu x86主机开发环境为例。
+
+
+使用工程的全量编译命令，编译生成内核镜像。
+
+
+```bash
+./build.sh --product-name rk3568					# 编译rk3568镜像版本。
+    --gn-args linux_kernel_version="linux-6.6"		# 编译指定内核版本，可选参数。
+													# 注意：目前选用linux内核的平台默认linux-6.6参与编译，
+													#       当前rk3568完成了Linux-6inux-6.6内核适配，即构建Linux-66不用指定，构建Linux-5.10版本需要该参数指定内核版本，
+													#       其他平台在适配完成前都必须添加该参数，指定Linux-5.10内核参与构建。
+```