Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
OpenHarmony
Docs
提交
ed8b2485
D
Docs
项目概览
OpenHarmony
/
Docs
12 个月 前同步成功
通知
159
Star
292
Fork
28
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
D
Docs
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
未验证
提交
ed8b2485
编写于
8月 05, 2022
作者:
O
openharmony_ci
提交者:
Gitee
8月 05, 2022
浏览文件
操作
浏览文件
下载
差异文件
!7809 冗余文件清理+碎片化整改---涉及翻译
Merge pull request !7809 from Austin/master
上级
473aeb6e
6d85f3fe
变更
9
展开全部
显示空白变更内容
内联
并排
Showing
9 changed file
with
2406 addition
and
49 deletion
+2406
-49
zh-cn/device-dev/kernel/Readme-CN.md
zh-cn/device-dev/kernel/Readme-CN.md
+7
-29
zh-cn/device-dev/kernel/kernel-mini-appx-lib.md
zh-cn/device-dev/kernel/kernel-mini-appx-lib.md
+495
-2
zh-cn/device-dev/kernel/kernel-mini-basic-memory.md
zh-cn/device-dev/kernel/kernel-mini-basic-memory.md
+316
-3
zh-cn/device-dev/kernel/kernel-mini-extend-file.md
zh-cn/device-dev/kernel/kernel-mini-extend-file.md
+287
-2
zh-cn/device-dev/kernel/kernel-mini-memory-debug.md
zh-cn/device-dev/kernel/kernel-mini-memory-debug.md
+331
-3
zh-cn/device-dev/kernel/kernel-small-bundles-fs-support.md
zh-cn/device-dev/kernel/kernel-small-bundles-fs-support.md
+416
-5
zh-cn/device-dev/kernel/kernel-small-debug-user.md
zh-cn/device-dev/kernel/kernel-small-debug-user.md
+545
-4
zh-cn/device-dev/porting/Readme-CN.md
zh-cn/device-dev/porting/Readme-CN.md
+2
-0
zh-cn/device-dev/subsystems/Readme-CN.md
zh-cn/device-dev/subsystems/Readme-CN.md
+7
-1
未找到文件。
zh-cn/device-dev/kernel/Readme-CN.md
浏览文件 @
ed8b2485
...
...
@@ -6,10 +6,7 @@
-
基础内核
-
[
中断管理
](
kernel-mini-basic-interrupt.md
)
-
[
任务管理
](
kernel-mini-basic-task.md
)
-
内存管理
-
[
基本概念
](
kernel-mini-basic-memory-basic.md
)
-
[
静态内存
](
kernel-mini-basic-memory-static.md
)
-
[
动态内存
](
kernel-mini-basic-memory-dynamic.md
)
-
[
内存管理
](
kernel-mini-basic-memory.md
)
-
内核通信机制
-
[
事件
](
kernel-mini-basic-ipc-event.md
)
-
[
互斥锁
](
kernel-mini-basic-ipc-mutex.md
)
...
...
@@ -21,23 +18,16 @@
-
[
C++支持
](
kernel-mini-extend-support.md
)
-
[
CPU占用率
](
kernel-mini-extend-cpup.md
)
-
[
动态加载
](
kernel-mini-extend-dynamic-loading.md
)
-
文件系统
-
[
FAT
](
kernel-mini-extend-file-fat.md
)
-
[
LittleFS
](
kernel-mini-extend-file-lit.md
)
-
[
文件系统
](
kernel-mini-extend-file.md
)
-
内核调测
-
内存调测
-
[
内存信息统计
](
kernel-mini-memory-debug-mes.md
)
-
[
内存泄漏检测
](
kernel-mini-memory-debug-det.md
)
-
[
踩内存检测
](
kernel-mini-memory-debug-cet.md
)
-
[
内存调测
](
kernel-mini-memory-debug.md
)
-
[
异常调测
](
kernel-mini-memory-exception.md
)
-
[
Trace调测
](
kernel-mini-memory-trace.md
)
-
[
LMS调测
](
kernel-mini-memory-lms.md
)
-
附录
-
[
内核编码规范
](
kernel-mini-appx-code.md
)
-
[
双向链表
](
kernel-mini-appx-data-list.md
)
-
标准库支持
-
[
CMSIS支持
](
kernel-mini-appx-lib-cmsis.md
)
-
[
POSIX支持
](
kernel-mini-appx-lib-posix.md
)
-
[
标准库支持
](
kernel-mini-appx-lib.md
)
-
小型系统内核
-
[
内核概述
](
kernel-small-overview.md
)
-
内核启动
...
...
@@ -71,13 +61,9 @@
-
[
虚拟动态共享库
](
kernel-small-bundles-share.md
)
-
[
轻量级进程间通信
](
kernel-small-bundles-ipc.md
)
-
文件系统
-
[
文件系统概述
](
kernel-small-bundles-fs.md
)
-
[
虚拟文件系统
](
kernel-small-bundles-fs-virtual.md
)
-
支持的文件系统
-
[
FAT
](
kernel-small-bundles-fs-support-fat.md
)
-
[
JFFS2
](
kernel-small-bundles-fs-support-jffs2.md
)
-
[
NFS
](
kernel-small-bundles-fs-support-nfs.md
)
-
[
Ramfs
](
kernel-small-bundles-fs-support-ramfs.md
)
-
[
Procfs
](
kernel-small-bundles-fs-support-procfs.md
)
-
[
支持的文件系统
](
kernel-small-bundles-fs-support.md
)
-
[
适配新的文件系统
](
kernel-small-bundles-fs-new.md
)
-
调测与工具
-
Shell
...
...
@@ -155,15 +141,7 @@
-
[
内存信息统计
](
kernel-small-debug-memory-info.md
)
-
[
内存泄漏检测
](
kernel-small-debug-memory-leak.md
)
-
[
踩内存检测
](
kernel-small-debug-memory-corrupt.md
)
-
用户态内存调测
-
[
基本概念
](
kernel-small-debug-user-concept.md
)
-
[
运行机制
](
kernel-small-debug-user-function.md
)
-
使用指导
-
[
接口说明
](
kernel-small-debug-user-guide-api.md
)
-
[
使用说明
](
kernel-small-debug-user-guide-use.md
)
-
[
接口调用方式
](
kernel-small-debug-user-guide-use-api.md
)
-
[
命令行参数方式
](
kernel-small-debug-user-guide-use-cli.md
)
-
[
常见问题
](
kernel-small-debug-user-faqs.md
)
-
[
用户态内存调测
](
kernel-small-debug-user.md
)
-
其他内核调测手段
-
[
临终遗言
](
kernel-small-debug-trace-other-lastwords.md
)
-
[
常见问题
](
kernel-small-debug-trace-other-faqs.md
)
...
...
zh-cn/device-dev/kernel/kernel-mini-appx-lib.md
浏览文件 @
ed8b2485
此差异已折叠。
点击以展开。
zh-cn/device-dev/kernel/kernel-mini-basic-memory.md
浏览文件 @
ed8b2485
# 内存管理
## 基本概念
内存管理模块管理系统的内存资源,它是操作系统的核心模块之一,主要包括内存的初始化、分配以及释放。
-
**[基本概念](kernel-mini-basic-memory-basic.md)**
-
**[静态内存](kernel-mini-basic-memory-static.md)**
在系统运行过程中,内存管理模块通过对内存的申请/释放来管理用户和OS对内存的使用,使内存的利用率和使用效率达到最优,同时最大限度地解决系统的内存碎片问题。
-
**[动态内存](kernel-mini-basic-memory-dynamic.md)**
\ No newline at end of file
OpenHarmony LiteOS-M的内存管理分为静态内存管理和动态内存管理,提供内存初始化、分配、释放等功能。
-
动态内存:在动态内存池中分配用户指定大小的内存块。
-
优点:按需分配。
-
缺点:内存池中可能出现碎片。
-
静态内存:在静态内存池中分配用户初始化时预设(固定)大小的内存块。
-
优点:分配和释放效率高,静态内存池中无碎片。
-
缺点:只能申请到初始化预设大小的内存块,不能按需申请。
## 静态内存
### 运行机制
静态内存实质上是一个静态数组,静态内存池内的块大小在初始化时设定,初始化后块大小不可变更。
静态内存池由一个控制块LOS_MEMBOX_INFO和若干相同大小的内存块LOS_MEMBOX_NODE构成。控制块位于内存池头部,用于内存块管理,包含内存块大小uwBlkSize,内存块数量uwBlkNum,已分配使用的内存块数量uwBlkCnt和空闲内存块链表stFreeList。内存块的申请和释放以块大小为粒度,每个内存块包含指向下一个内存块的指针pstNext。
**图1**
静态内存示意图
!
[
zh-cn_image_0000001199352039
](
figures/zh-cn_image_0000001199352039.png
)
### 开发指导
#### 使用场景
当用户需要使用固定长度的内存时,可以通过静态内存分配的方式获取内存,一旦使用完毕,通过静态内存释放函数归还所占用内存,使之可以重复使用。
#### 接口说明
OpenHarmony LiteOS-M的静态内存管理主要为用户提供以下功能,接口详细信息可以查看API参考。
**表1**
静态内存模块接口
| 功能分类 | 接口名 |
| -------- | -------- |
| 初始化静态内存池 | LOS_MemboxInit:初始化一个静态内存池,根据入参设定其起始地址、总大小及每个内存块大小。 |
| 清除静态内存块内容 | LOS_MemboxClr:清零从静态内存池中申请的静态内存块的内容。 |
| 申请、释放静态内存 | -
LOS_MemboxAlloc:从指定的静态内存池中申请一块静态内存块。
<br/>
-
LOS_MemboxFree:释放从静态内存池中申请的一块静态内存块。 |
| 获取、打印静态内存池信息 | -
LOS_MemboxStatisticsGet:获取指定静态内存池的信息,包括内存池中总内存块数量、已经分配出去的内存块数量、每个内存块的大小。
<br/>
-
LOS_ShowBox:打印指定静态内存池所有节点信息(打印等级是LOS_INFO_LEVEL),包括内存池起始地址、内存块大小、总内存块数量、每个空闲内存块的起始地址、所有内存块的起始地址。 |
> ![icon-note.gif](public_sys-resources/icon-note.gif) **说明:**
> 初始化后的内存池的内存块数量,不等于总大小除于内存块大小,因为内存池的控制块和每个内存块的控制头,都存在内存开销,设置总大小时,需要将这些因素考虑进去。
#### 开发流程
本节介绍使用静态内存的典型场景开发流程。
1.
规划一片内存区域作为静态内存池。
2.
调用LOS_MemboxInit初始化静态内存池。
初始化会将入参指定的内存区域分割为N块(N值取决于静态内存总大小和块大小),将所有内存块挂到空闲链表,在内存起始处放置控制头。
3.
调用LOS_MemboxAlloc接口分配静态内存。
系统将会从空闲链表中获取第一个空闲块,并返回该内存块的起始地址。
4.
调用LOS_MemboxClr接口。
将入参地址对应的内存块清零。
5.
调用LOS_MemboxFree接口。
将该内存块加入空闲链表。
#### 编程实例
本实例执行以下步骤:
1.
初始化一个静态内存池。
2.
从静态内存池中申请一块静态内存。
3.
在内存块存放一个数据。
4.
打印出内存块中的数据。
5.
清除内存块中的数据。
6.
释放该内存块。
示例代码如下:
```
#include "los_membox.h"
VOID Example_StaticMem(VOID)
{
UINT32 *mem = NULL;
UINT32 blkSize = 10;
UINT32 boxSize = 100;
UINT32 boxMem[1000];
UINT32 ret;
/*内存池初始化*/
ret = LOS_MemboxInit(&boxMem[0], boxSize, blkSize);
if(ret != LOS_OK) {
printf("Membox init failed!\n");
return;
} else {
printf("Membox init success!\n");
}
/*申请内存块*/
mem = (UINT32 *)LOS_MemboxAlloc(boxMem);
if (NULL == mem) {
printf("Mem alloc failed!\n");
return;
}
printf("Mem alloc success!\n");
/*赋值*/
*mem = 828;
printf("*mem = %d\n", *mem);
/*清除内存内容*/
LOS_MemboxClr(boxMem, mem);
printf("Mem clear success \n *mem = %d\n", *mem);
/*释放内存*/
ret = LOS_MemboxFree(boxMem, mem);
if (LOS_OK == ret) {
printf("Mem free success!\n");
} else {
printf("Mem free failed!\n");
}
return;
}
```
#### 结果验证
输出结果如下:
```
Membox init success!
Mem alloc success!
*mem = 828
Mem clear success
*mem = 0
Mem free success!
```
## 动态内存
### 运行机制
动态内存管理,即在内存资源充足的情况下,根据用户需求,从系统配置的一块比较大的连续内存(内存池,也是堆内存)中分配任意大小的内存块。当用户不需要该内存块时,又可以释放回系统供下一次使用。与静态内存相比,动态内存管理的优点是按需分配,缺点是内存池中容易出现碎片。
OpenHarmony LiteOS-M动态内存在TLSF算法的基础上,对区间的划分进行了优化,获得更优的性能,降低了碎片率。动态内存核心算法框图如下:
**图1**
轻量系统动态内存核心算法
!
[
zh-cn_image_0000001199352445
](
figures/zh-cn_image_0000001199352445.png
)
根据空闲内存块的大小,使用多个空闲链表来管理。根据内存空闲块大小分为两个部分:[4, 127]和[2
<sup>
7
</sup>
, 2
<sup>
31
</sup>
],如上图size class所示:
1.
对[4,127]区间的内存进行等分,如上图下半部分所示,分为31个小区间,每个小区间对应内存块大小为4字节的倍数。每个小区间对应一个空闲内存链表和用于标记对应空闲内存链表是否为空的一个比特位,值为1时,空闲链表非空。[4,127]区间的31个小区间内存对应31个比特位进行标记链表是否为空。
2.
大于127字节的空闲内存块,按照2的次幂区间大小进行空闲链表管理。总共分为24个小区间,每个小区间又等分为8个二级小区间,见上图上半部分的Size Class和Size SubClass部分。每个二级小区间对应一个空闲链表和用于标记对应空闲内存链表是否为空的一个比特位。总共24
\*
8=192个二级小区间,对应192个空闲链表和192个比特位进行标记链表是否为空。
例如,当有40字节的空闲内存需要插入空闲链表时,对应小区间[40,43],第10个空闲链表,位图标记的第10比特位。把40字节的空闲内存挂载第10个空闲链表上,并判断是否需要更新位图标记。当需要申请40字节的内存时,根据位图标记获取存在满足申请大小的内存块的空闲链表,从空闲链表上获取空闲内存节点。如果分配的节点大于需要申请的内存大小,进行分割节点操作,剩余的节点重新挂载到相应的空闲链表上。当有580字节的空闲内存需要插入空闲链表时,对应二级小区间[2^9,2^9+2^6],第31+2
\*
8=47个空闲链表,并使用位图的第47个比特位来标记链表是否为空。把580字节的空闲内存挂载第47个空闲链表上,并判断是否需要更新位图标记。当需要申请580字节的内存时,根据位图标记获取存在满足申请大小的内存块的空闲链表,从空闲链表上获取空闲内存节点。如果分配的节点大于需要申请的内存大小,进行分割节点操作,剩余的节点重新挂载到相应的空闲链表上。如果对应的空闲链表为空,则向更大的内存区间去查询是否有满足条件的空闲链表,实际计算时,会一次性查找到满足申请大小的空闲链表。
内存管理结构如下图所示:
**图2**
轻量系统动态内存管理结构图
!
[
zh-cn_image_0000001153313284
](
figures/zh-cn_image_0000001153313284.png
)
-
内存池池头部分
内存池池头部分包含内存池信息、位图标记数组和空闲链表数组。内存池信息包含内存池起始地址及堆区域总大小,内存池属性。位图标记数组有7个32位无符号整数组成,每个比特位标记对应的空闲链表是否挂载空闲内存块节点。空闲内存链表包含223个空闲内存头节点信息,每个空闲内存头节点信息维护内存节点头和空闲链表中的前驱、后继空闲内存节点。
-
内存池节点部分
包含3种类型节点:未使用空闲内存节点,已使用内存节点和尾节点。每个内存节点维护一个前序指针,指向内存池中上一个内存节点,还维护内存节点的大小和使用标记。空闲内存节点和已使用内存节点后面的内存区域是数据域,尾节点没有数据域。
一些芯片片内RAM大小无法满足要求,需要使用片外物理内存进行扩充。对于这样的多段非连续性内存, LiteOS-M内核支持把多个非连续性内存逻辑上合一,用户不感知底层的多段非连续性内存区域。 LiteOS-M内核内存模块把不连续的内存区域作为空闲内存结点插入到空闲内存节点链表,把不同内存区域间的不连续部分标记为虚拟的已使用内存节点,从逻辑上把多个非连续性内存区域实现为一个统一的内存池。下面通过示意图说明下多段非连续性内存的运行机制:
**图3**
非连续性内存合一示意图
!
[
zh-cn_image_0000001198253551
](
figures/zh-cn_image_0000001198253551.png
)
结合上述示意图,非连续性内存合并为一个统一的内存池的步骤如下:
1.
把多段非连续性内存区域的第一块内存区域通过调用LOS_MemInit接口进行初始化。
2.
获取下一个内存区域的开始地址和长度,计算该内存区域和上一块内存区域的间隔大小gapSize。
3.
把内存区域间隔部分视为虚拟的已使用节点,使用上一个内存区域的尾节点,设置其大小为gapSize+ OS_MEM_NODE_HEAD_SIZE。
4.
把当前内存区域划分为一个空闲内存节点和一个尾节点,把空闲内存节点插入到空闲链表,并设置各个节点的前后链接关系。
5.
如果有更多的非连续内存区域,重复上述步骤2-4。
### 开发指导
#### 使用场景
动态内存管理的主要工作是动态分配并管理用户申请到的内存区间。动态内存管理主要用于用户需要使用大小不等的内存块的场景,当用户需要使用内存时,可以通过操作系统的动态内存申请函数索取指定大小的内存块,一旦使用完毕,通过动态内存释放函数归还所占用内存,使之可以重复使用。
#### 接口说明
OpenHarmony LiteOS-M的动态内存管理主要为用户提供以下功能,接口详细信息可以查看API参考。
**表1**
动态内存模块接口
| 功能分类 | 接口描述 |
| -------- | -------- |
| 初始化和删除内存池 | -
LOS_MemInit:初始化一块指定的动态内存池,大小为size。
<br/>
-
LOS_MemDeInit:删除指定内存池,仅打开LOSCFG_MEM_MUL_POOL时有效。 |
| 申请、释放动态内存 | -
LOS_MemAlloc:从指定动态内存池中申请size长度的内存。
<br/>
-
LOS_MemFree:释放从指定动态内存中申请的内存。
<br/>
-
LOS_MemRealloc:释放从指定动态内存中申请的内存。 |
| 获取内存池信息 | -
LOS_MemPoolSizeGet:获取指定动态内存池的总大小。
<br/>
-
LOS_MemTotalUsedGet:获取指定动态内存池的总使用量大小。
<br/>
-
LOS_MemInfoGet:获取指定内存池的内存结构信息,包括空闲内存大小、已使用内存大小、空闲内存块数量、已使用的内存块数量、最大的空闲内存块大小。
<br/>
-
LOS_MemPoolList:打印系统中已初始化的所有内存池,包括内存池的起始地址、内存池大小、空闲内存总大小、已使用内存总大小、最大的空闲内存块大小、空闲内存块数量、已使用的内存块数量。仅打开LOSCFG_MEM_MUL_POOL时有效。 |
| 获取内存块信息 | -
LOS_MemFreeNodeShow:打印指定内存池的空闲内存块的大小及数量。
<br/>
-
LOS_MemUsedNodeShow:打印指定内存池的已使用内存块的大小及数量。 |
| 检查指定内存池的完整性 | LOS_MemIntegrityCheck:对指定内存池做完整性检查,仅打开LOSCFG_BASE_MEM_NODE_INTEGRITY_CHECK时有效。 |
| 增加非连续性内存区域 | LOS_MemRegionsAdd:支持多段非连续性内存区域,把非连续性内存区域逻辑上整合为一个统一的内存池。仅打开LOSCFG_MEM_MUL_REGIONS时有效。如果内存池指针参数pool为空,则使用多段内存的第一个初始化为内存池,其他内存区域,作为空闲节点插入;如果内存池指针参数pool不为空,则把多段内存作为空闲节点,插入到指定的内存池。 |
> ![icon-note.gif](public_sys-resources/icon-note.gif) **说明:**
> - 由于动态内存管理需要管理控制块数据结构来管理内存,这些数据结构会额外消耗内存,故实际用户可使用内存总量小于配置项OS_SYS_MEM_SIZE的大小。
>
> - 对齐分配内存接口LOS_MemAllocAlign/LOS_MemMallocAlign因为要进行地址对齐,可能会额外消耗部分内存,故存在一些遗失内存,当系统释放该对齐内存时,同时回收由于对齐导致的遗失内存。
>
> - 非连续性内存区域接口LOS_MemRegionsAdd的LosMemRegion数组参数传入的非连续性内存区域需要按各个内存区域的内存开始地址升序,且内存区域不能重叠。
#### 开发流程
本节介绍使用动态内存的典型场景开发流程。
1.
初始化LOS_MemInit。
初始一个内存池后生成一个内存池控制头、尾节点EndNode,剩余的内存被标记为FreeNode内存节点。注:EndNode作为内存池末尾的节点,size为0。
1.
申请任意大小的动态内存LOS_MemAlloc。
判断动态内存池中是否存在大于申请量大小的空闲内存块空间,若存在,则划出一块内存块,以指针形式返回,若不存在,返回NULL。如果空闲内存块大于申请量,需要对内存块进行分割,剩余的部分作为空闲内存块挂载到空闲内存链表上。
1.
释放动态内存LOS_MemFree。
回收内存块,供下一次使用。调用LOS_MemFree释放内存块,则会回收内存块,并且将其标记为FreeNode。在回收内存块时,相邻的FreeNode会自动合并。
#### 编程实例
本实例执行以下步骤:
1.
初始化一个动态内存池。
2.
从动态内存池中申请一个内存块。
3.
在内存块中存放一个数据。
4.
打印出内存块中的数据。
5.
释放该内存块。
示例代码如下:
```
#include "los_memory.h"
#define TEST_POOL_SIZE (2*1024)
__attribute__((aligned(4))) UINT8 g_testPool[TEST_POOL_SIZE];
VOID Example_DynMem(VOID)
{
UINT32 *mem = NULL;
UINT32 ret;
/*初始化内存池*/
ret = LOS_MemInit(g_testPool, TEST_POOL_SIZE);
if (LOS_OK == ret) {
printf("Mem init success!\n");
} else {
printf("Mem init failed!\n");
return;
}
/*分配内存*/
mem = (UINT32 *)LOS_MemAlloc(g_testPool, 4);
if (NULL == mem) {
printf("Mem alloc failed!\n");
return;
}
printf("Mem alloc success!\n");
/*赋值*/
*mem = 828;
printf("*mem = %d\n", *mem);
/*释放内存*/
ret = LOS_MemFree(g_testPool, mem);
if (LOS_OK == ret) {
printf("Mem free success!\n");
} else {
printf("Mem free failed!\n");
}
return;
}
```
#### 结果验证
输出结果如下:
```
Mem init success!
Mem alloc success!
*mem = 828
Mem free success!
```
zh-cn/device-dev/kernel/kernel-mini-extend-file.md
浏览文件 @
ed8b2485
...
...
@@ -40,7 +40,292 @@ M核的文件系统子系统当前支持的文件系统有FATFS与LittleFS。同
| umount2 | 分区卸载,可通过MNT_FORCE参数进行强制卸载 | 支持 | 不支持 |
| statfs | 获取分区信息 | 支持 | 不支持 |
## FAT
-
**[FAT](kernel-mini-extend-file-fat.md)**
-
**[LittleFS](kernel-mini-extend-file-lit.md)**
\ No newline at end of file
### 基本概念
FAT文件系统是File Allocation Table(文件配置表)的简称,主要包括DBR区、FAT区、DATA区三个区域。其中,FAT区各个表项记录存储设备中对应簇的信息,包括簇是否被使用、文件下一个簇的编号、是否文件结尾等。FAT文件系统有FAT12、FAT16、FAT32等多种格式,其中,12、16、32表示对应格式中FAT表项的比特数。FAT文件系统支持多种介质,特别在可移动存储介质(U盘、SD卡、移动硬盘等)上广泛使用,使嵌入式设备和Windows、Linux等桌面系统保持很好的兼容性,方便用户管理操作文件。
OpenHarmony内核支持FAT12、FAT16与FAT32三种格式的FAT文件系统,具有代码量小、资源占用小、可裁切、支持多种物理介质等特性,并且与Windows、Linux等系统保持兼容,支持多设备、多分区识别等功能。OpenHarmony内核支持硬盘多分区,可以在主分区以及逻辑分区上创建FAT文件系统。
### 开发指导
#### 驱动适配
FAT文件系统的使用需要底层MMC相关驱动的支持。在一个带MMC存储设备的板子上运行FATFS,需要:
1、适配板端EMMC驱动,实现disk_status、disk_initialize、disk_read、disk_write、disk_ioctl接口;
2、新增fs_config.h文件,配置FS_MAX_SS(存储设备最大sector大小)、FF_VOLUME_STRS(分区名)等信息,例如:
```
#define FF_VOLUME_STRS "system", "inner", "update", "user"
#define FS_MAX_SS 512
#define FAT_MAX_OPEN_FILES 50
```
#### 开发流程
> ![icon-note.gif](public_sys-resources/icon-note.gif) **说明:**
> - FATFS文件与目录操作:
> - 单个文件大小不超过4G。
> - 支持同时打开的文件数最大为FAT_MAX_OPEN_FILES,文件夹数最大为FAT_MAX_OPEN_DIRS。
> - 暂不支持根目录管理,文件/目录名均以分区名开头,例如“user/testfile”就是在“user”分区下名为“testfile”的文件或目录。
> - 若需要同时多次打开同一文件,必须全部使用只读方式(O_RDONLY)。以可写方式(O_RDWR、O_WRONLY等)只能打开一次。
> - 读写指针未分离,例如以O_APPEND(追加写)方式打开文件后,读指针也在文件尾,从头读文件前需要用户手动置位。
> - 暂不支持文件与目录的权限管理。
> - stat及fstat接口暂不支持查询修改时间、创建时间和最后访问时间。微软FAT协议不支持1980年以前的时间。
>
> - FATFS分区挂载与卸载:
> - 支持以只读属性挂载分区。当mount函数的入参为MS_RDONLY时,所有的带有写入的接口,如write、mkdir、unlink,以及非O_RDONLY属性的open,将均被拒绝。
> - mount支持通过MS_REMOUNT标记修改已挂载分区的权限。
> - 在umount操作前,需确保所有目录及文件全部关闭。
> - umount2支持通过MNT_FORCE参数强制关闭所有文件与文件夹并umount,但可能造成数据丢失,请谨慎使用。
>
> - FATFS支持重新划分存储设备分区、格式化分区,对应接口为fatfs_fdisk与fatfs_format:
> - 在fatfs_format操作之前,若需要格式化的分区已挂载,需确保分区中的所有目录及文件全部关闭,并且分区umount。
> - 在fatfs_fdisk操作前,需要该设备中的所有分区均已umount。
> - fatfs_fdisk与fatfs_format会造成设备数据丢失,请谨慎使用。
### 编程实例
#### 实例描述
本实例实现以下功能:
1.
创建目录“user/test”
2.
在“user/test”目录下创建文件“file.txt”
3.
在文件起始位置写入“Hello OpenHarmony!”
4.
将文件内容刷入设备中
5.
设置偏移到文件起始位置
6.
读取文件内容
7.
关闭文件
8.
删除文件
9.
删除目录
#### 示例代码
**前提条件:**
系统已将MMC设备分区挂载到user目录
**代码实现如下:**
```
#include <stdio.h>
#include <string.h>
#include "sys/stat.h"
#include "fcntl.h"
#include "unistd.h"
#define LOS_OK 0
#define LOS_NOK -1
int FatfsTest(void)
{
int ret;
int fd = -1;
ssize_t len;
off_t off;
char dirName[20] = "user/test";
char fileName[20] = "user/test/file.txt";
char writeBuf[20] = "Hello OpenHarmony!";
char readBuf[20] = {0};
/* 创建目录“user/test” */
ret = mkdir(dirName, 0777);
if (ret != LOS_OK) {
printf("mkdir failed.\n");
return LOS_NOK;
}
/* 创建可读写文件"user/test/file.txt" */
fd = open(fileName, O_RDWR | O_CREAT, 0777);
if (fd < 0) {
printf("open file failed.\n");
return LOS_NOK;
}
/* 将writeBuf中的内容写入文件 */
len = write(fd, writeBuf, strlen(writeBuf));
if (len != strlen(writeBuf)) {
printf("write file failed.\n");
return LOS_NOK;
}
/* 将文件内容刷入存储设备中 */
ret = fsync(fd);
if (ret != LOS_OK) {
printf("fsync failed.\n");
return LOS_NOK;
}
/* 将读写指针偏移至文件头 */
off = lseek(fd, 0, SEEK_SET);
if (off != 0) {
printf("lseek failed.\n");
return LOS_NOK;
}
/* 将文件内容读出至readBuf中,读取长度为readBuf大小 */
len = read(fd, readBuf, sizeof(readBuf));
if (len != strlen(writeBuf)) {
printf("read file failed.\n");
return LOS_NOK;
}
printf("%s\n", readBuf);
/* 关闭文件 */
ret = close(fd);
if (ret != LOS_OK) {
printf("close failed.\n");
return LOS_NOK;
}
/* 删除文件"user/test/file.txt" */
ret = unlink(fileName);
if (ret != LOS_OK) {
printf("unlink failed.\n");
return LOS_NOK;
}
/* 删除目录“user/test” */
ret = rmdir(dirName);
if (ret != LOS_OK) {
printf("rmdir failed.\n");
return LOS_NOK;
}
return LOS_OK;
}
```
#### 结果验证
编译运行得到的结果为:
```
Hello OpenHarmony!
```
## LittleFS
### 基本概念
LittleFS是一个小型的Flash文件系统,它结合日志结构(log-structured)文件系统和COW(copy-on-write)文件系统的思想,以日志结构存储元数据,以COW结构存储数据。这种特殊的存储方式,使LittleFS具有强大的掉电恢复能力(power-loss resilience)。分配COW数据块时LittleFS采用了名为统计损耗均衡的动态损耗均衡算法,使Flash设备的寿命得到有效保障。同时LittleFS针对资源紧缺的小型设备进行设计,具有极其有限的ROM和RAM占用,并且所有RAM的使用都通过一个可配置的固定大小缓冲区进行分配,不会随文件系统的扩大占据更多的系统资源。
当在一个资源非常紧缺的小型设备上,寻找一个具有掉电恢复能力并支持损耗均衡的Flash文件系统时,LittleFS是一个比较好的选择。
### 开发指导
移植LittleFS到新硬件设备上,需要申明lfs_config:
```
const struct lfs_config cfg = {
// block device operations
.read = user_provided_block_device_read,
.prog = user_provided_block_device_prog,
.erase = user_provided_block_device_erase,
.sync = user_provided_block_device_sync,
// block device configuration
.read_size = 16,
.prog_size = 16,
.block_size = 4096,
.block_count = 128,
.cache_size = 16,
.lookahead_size = 16,
.block_cycles = 500,
};
```
其中.read,.prog,.erase,.sync分别对应该硬件平台上的底层的读写
\擦
除
\同
步等接口。
read_size 每次读取的字节数,可以比物理读单元大以改善性能,这个数值决定了读缓存的大小,但值太大会带来更多的内存消耗。
prog_size 每次写入的字节数,可以比物理写单元大以改善性能,这个数值决定了写缓存的大小,必须是read_size的整数倍,但值太大会带来更多的内存消耗。
block_size 每个擦除块的字节数,可以比物理擦除单元大,但此数值应尽可能小因为每个文件至少会占用一个块。必须是prog_size的整数倍。
block_count 可以被擦除的块数量,这取决于块设备的容量及擦除块的大小。
### 示例代码
代码实现如下:
```
#include "lfs.h"
#include "stdio.h"
lfs_t lfs;
lfs_file_t file;
const struct lfs_config cfg = {
// block device operations
.read = user_provided_block_device_read,
.prog = user_provided_block_device_prog,
.erase = user_provided_block_device_erase,
.sync = user_provided_block_device_sync,
// block device configuration
.read_size = 16,
.prog_size = 16,
.block_size = 4096,
.block_count = 128,
.cache_size = 16,
.lookahead_size = 16,
.block_cycles = 500,
};
int main(void) {
// mount the filesystem
int err = lfs_mount(&lfs, &cfg);
// reformat if we can't mount the filesystem
// this should only happen on the first boot
if (err) {
lfs_format(&lfs, &cfg);
lfs_mount(&lfs, &cfg);
}
// read current count
uint32_t boot_count = 0;
lfs_file_open(&lfs, &file, "boot_count", LFS_O_RDWR | LFS_O_CREAT);
lfs_file_read(&lfs, &file, &boot_count, sizeof(boot_count));
// update boot count
boot_count += 1;
lfs_file_rewind(&lfs, &file);
lfs_file_write(&lfs, &file, &boot_count, sizeof(boot_count));
// remember the storage is not updated until the file is closed successfully
lfs_file_close(&lfs, &file);
// release any resources we were using
lfs_unmount(&lfs);
// print the boot count
printf("boot_count: %d\n", boot_count);
}
```
**结果验证**
首次编译运行得到的结果为:
```
Say hello 1 times.
```
\ No newline at end of file
zh-cn/device-dev/kernel/kernel-mini-memory-debug.md
浏览文件 @
ed8b2485
...
...
@@ -4,8 +4,336 @@
内存调测方法旨在辅助定位动态内存相关问题,提供了基础的动态内存池信息统计手段,向用户呈现内存池水线、碎片率等信息;提供了内存泄漏检测手段,方便用户准确定位存在内存泄漏的代码行,也可以辅助分析系统各个模块内存的使用情况;提供了踩内存检测手段,可以辅助定位越界踩内存的场景。
-
**[内存信息统计](kernel-mini-memory-debug-mes.md)**
## 内存信息统计
-
**[内存泄漏检测](kernel-mini-memory-debug-det.md)**
-
**[踩内存检测](kernel-mini-memory-debug-cet.md)**
\ No newline at end of file
### 基础概念
内存信息包括内存池大小、内存使用量、剩余内存大小、最大空闲内存、内存水线、内存节点数统计、碎片率等。
-
内存水线:即内存池的最大使用量,每次申请和释放时,都会更新水线值,实际业务可根据该值,优化内存池大小;
-
碎片率:衡量内存池的碎片化程度,碎片率高表现为内存池剩余内存很多,但是最大空闲内存块很小,可以用公式(fragment=100-100
\*
最大空闲内存块大小/剩余内存大小)来度量;
-
其他参数:通过调用接口(详见
[
内存管理
](
../kernel/kernel-mini-basic-memory-basic.md
)
章节接口说明),扫描内存池的节点信息,统计出相关信息。
### 功能配置
LOSCFG_MEM_WATERLINE:开关宏,默认打开;若关闭这个功能,在target_config.h中将这个宏定义为0。如需获取内存水线,需要打开该配置。
### 开发指导
#### 开发流程
关键结构体介绍:
```
typedef struct {
UINT32 totalUsedSize; // 内存池的内存使用量
UINT32 totalFreeSize; // 内存池的剩余内存大小
UINT32 maxFreeNodeSize; // 内存池的最大空闲内存块大小
UINT32 usedNodeNum; // 内存池的非空闲内存块个数
UINT32 freeNodeNum; // 内存池的空闲内存块个数
#if (LOSCFG_MEM_WATERLINE == 1) // 默认打开,如需关闭,在target_config.h中将该宏设置为0
UINT32 usageWaterLine; // 内存池的水线值
#endif
} LOS_MEM_POOL_STATUS;
```
-
内存水线获取:调用LOS_MemInfoGet接口,第1个参数是内存池首地址,第2个参数是LOS_MEM_POOL_STATUS类型的句柄,其中字段usageWaterLine即水线值。
-
内存碎片率计算:同样调用LOS_MemInfoGet接口,可以获取内存池的剩余内存大小和最大空闲内存块大小,然后根据公式(fragment=100-100
\*
最大空闲内存块大小/剩余内存大小)得出此时的动态内存池碎片率。
#### 编程实例
本实例实现如下功能:
1.
创建一个监控任务,用于获取内存池的信息;
2.
调用LOS_MemInfoGet接口,获取内存池的基础信息;
3.
利用公式算出使用率及碎片率。
#### 示例代码
代码实现如下:
```
#include <stdio.h>
#include <string.h>
#include "los_task.h"
#include "los_memory.h"
#include "los_config.h"
void MemInfoTaskFunc(void)
{
LOS_MEM_POOL_STATUS poolStatus = {0};
/* pool为要统计信息的内存地址,此处以OS_SYS_MEM_ADDR为例 */
void *pool = OS_SYS_MEM_ADDR;
LOS_MemInfoGet(pool, &poolStatus);
/* 算出内存池当前的碎片率百分比 */
unsigned char fragment = 100 - poolStatus.maxFreeNodeSize * 100 / poolStatus.totalFreeSize;
/* 算出内存池当前的使用率百分比 */
unsigned char usage = LOS_MemTotalUsedGet(pool) * 100 / LOS_MemPoolSizeGet(pool);
printf("usage = %d, fragment = %d, maxFreeSize = %d, totalFreeSize = %d, waterLine = %d\n", usage, fragment, poolStatus.maxFreeNodeSize,
poolStatus.totalFreeSize, poolStatus.usageWaterLine);
}
int MemTest(void)
{
unsigned int ret;
unsigned int taskID;
TSK_INIT_PARAM_S taskStatus = {0};
taskStatus.pfnTaskEntry = (TSK_ENTRY_FUNC)MemInfoTaskFunc;
taskStatus.uwStackSize = 0x1000;
taskStatus.pcName = "memInfo";
taskStatus.usTaskPrio = 10;
ret = LOS_TaskCreate(&taskID, &taskStatus);
if (ret != LOS_OK) {
printf("task create failed\n");
return -1;
}
return 0;
}
```
#### 结果验证
编译运行输出的结果如下:
```
usage = 22, fragment = 3, maxFreeSize = 49056, totalFreeSize = 50132, waterLine = 1414
```
## 内存泄漏检测
### 基础概念
内存泄漏检测机制作为内核的可选功能,用于辅助定位动态内存泄漏问题。开启该功能,动态内存机制会自动记录申请内存时的函数调用关系(下文简称LR)。如果出现泄漏,就可以利用这些记录的信息,找到内存申请的地方,方便进一步确认。
### 功能配置
1.
LOSCFG_MEM_LEAKCHECK:开关宏,默认关闭;若打开这个功能,在target_config.h中将这个宏定义为1。
2.
LOSCFG_MEM_RECORD_LR_CNT:记录的LR层数,默认3层;每层LR消耗sizeof(void
\*
)字节数的内存。
3.
LOSCFG_MEM_OMIT_LR_CNT:忽略的LR层数,默认4层,即从调用LOS_MemAlloc的函数开始记录,可根据实际情况调整。为啥需要这个配置?有3点原因如下:
-
LOS_MemAlloc接口内部也有函数调用;
-
外部可能对LOS_MemAlloc接口有封装;
-
LOSCFG_MEM_RECORD_LR_CNT 配置的LR层数有限;
正确配置这个宏,将无效的LR层数忽略,就可以记录有效的LR层数,节省内存消耗。
### 开发指导
#### 开发流程
该调测功能可以分析关键的代码逻辑中是否存在内存泄漏。开启这个功能,每次申请内存时,会记录LR信息。在需要检测的代码段前后,调用LOS_MemUsedNodeShow接口,每次都会打印指定内存池已使用的全部节点信息,对比前后两次的节点信息,新增的节点信息就是疑似泄漏的内存节点。通过LR,可以找到具体申请的代码位置,进一步确认是否泄漏。
调用LOS_MemUsedNodeShow接口输出的节点信息格式如下:每1行为一个节点信息;第1列为节点地址,可以根据这个地址,使用GDB等手段查看节点完整信息;第2列为节点的大小,等于节点头大小+数据域大小;第3~5列为函数调用关系LR地址,可以根据这个值,结合汇编文件,查看该节点具体申请的位置。
```
node size LR[0] LR[1] LR[2]
0x10017320: 0x528 0x9b004eba 0x9b004f60 0x9b005002
0x10017848: 0xe0 0x9b02c24e 0x9b02c246 0x9b008ef0
0x10017928: 0x50 0x9b008ed0 0x9b068902 0x9b0687c4
0x10017978: 0x24 0x9b008ed0 0x9b068924 0x9b0687c4
0x1001799c: 0x30 0x9b02c24e 0x9b02c246 0x9b008ef0
0x100179cc: 0x5c 0x9b02c24e 0x9b02c246 0x9b008ef0
```
> ![icon-caution.gif](public_sys-resources/icon-caution.gif) **注意:**
> 开启内存检测会影响内存申请的性能,且每个内存节点都会记录LR地址,内存开销也加大。
#### 编程实例
本实例实现如下功能:构建内存泄漏代码段。
1.
调用LOS_MemUsedNodeShow接口,输出全部节点信息打印;
2.
申请内存,但没有释放,模拟内存泄漏;
3.
再次调用LOS_MemUsedNodeShow接口,输出全部节点信息打印;
4.
将两次log进行对比,得出泄漏的节点信息;
5.
通过LR地址,找出泄漏的代码位置;
#### 示例代码
代码实现如下:
```
#include <stdio.h>
#include <string.h>
#include "los_memory.h"
#include "los_config.h"
void MemLeakTest(void)
{
LOS_MemUsedNodeShow(LOSCFG_SYS_HEAP_ADDR);
void *ptr1 = LOS_MemAlloc(LOSCFG_SYS_HEAP_ADDR, 8);
void *ptr2 = LOS_MemAlloc(LOSCFG_SYS_HEAP_ADDR, 8);
LOS_MemUsedNodeShow(LOSCFG_SYS_HEAP_ADDR);
}
```
#### 结果验证
编译运行输出log如下:
```
node size LR[0] LR[1] LR[2]
0x20001b04: 0x24 0x08001a10 0x080035ce 0x080028fc
0x20002058: 0x40 0x08002fe8 0x08003626 0x080028fc
0x200022ac: 0x40 0x08000e0c 0x08000e56 0x0800359e
0x20002594: 0x120 0x08000e0c 0x08000e56 0x08000c8a
0x20002aac: 0x56 0x08000e0c 0x08000e56 0x08004220
node size LR[0] LR[1] LR[2]
0x20001b04: 0x24 0x08001a10 0x080035ce 0x080028fc
0x20002058: 0x40 0x08002fe8 0x08003626 0x080028fc
0x200022ac: 0x40 0x08000e0c 0x08000e56 0x0800359e
0x20002594: 0x120 0x08000e0c 0x08000e56 0x08000c8a
0x20002aac: 0x56 0x08000e0c 0x08000e56 0x08004220
0x20003ac4: 0x1d 0x08001458 0x080014e0 0x080041e6
0x20003ae0: 0x1d 0x080041ee 0x08000cc2 0x00000000
```
对比两次log,差异如下,这些内存节点就是疑似泄漏的内存块:
```
0x20003ac4: 0x1d 0x08001458 0x080014e0 0x080041e6
0x20003ae0: 0x1d 0x080041ee 0x08000cc2 0x00000000
```
部分汇编文件如下:
```
MemLeakTest:
0x80041d4: 0xb510 PUSH {R4, LR}
0x80041d6: 0x4ca8 LDR.N R4, [PC, #0x2a0] ; g_memStart
0x80041d8: 0x0020 MOVS R0, R4
0x80041da: 0xf7fd 0xf93e BL LOS_MemUsedNodeShow ; 0x800145a
0x80041de: 0x2108 MOVS R1, #8
0x80041e0: 0x0020 MOVS R0, R4
0x80041e2: 0xf7fd 0xfbd9 BL LOS_MemAlloc ; 0x8001998
0x80041e6: 0x2108 MOVS R1, #8
0x80041e8: 0x0020 MOVS R0, R4
0x80041ea: 0xf7fd 0xfbd5 BL LOS_MemAlloc ; 0x8001998
0x80041ee: 0x0020 MOVS R0, R4
0x80041f0: 0xf7fd 0xf933 BL LOS_MemUsedNodeShow ; 0x800145a
0x80041f4: 0xbd10 POP {R4, PC}
0x80041f6: 0x0000 MOVS R0, R0
```
其中,通过查找0x080041ee,就可以发现该内存节点是在MemLeakTest接口里申请的且是没有释放的。
## 踩内存检测
### 基础概念
踩内存检测机制作为内核的可选功能,用于检测动态内存池的完整性。通过该机制,可以及时发现内存池是否发生了踩内存问题,并给出错误信息,便于及时发现系统问题,提高问题解决效率,降低问题定位成本。
### 功能配置
LOSCFG_BASE_MEM_NODE_INTEGRITY_CHECK:开关宏,默认关闭;若打开这个功能,在target_config.h中将这个宏定义为1。
1.
开启这个功能,每次申请内存,会实时检测内存池的完整性。
2.
如果不开启该功能,也可以调用LOS_MemIntegrityCheck接口检测,但是每次申请内存时,不会实时检测内存完整性,而且由于节点头没有魔鬼数字(开启时才有,省内存),检测的准确性也会相应降低,但对于系统的性能没有影响,故根据实际情况开关该功能。
由于该功能只会检测出哪个内存节点被破坏了,并给出前节点信息(因为内存分布是连续的,当前节点最有可能被前节点破坏)。如果要进一步确认前节点在哪里申请的,需开启内存泄漏检测功能,通过LR记录,辅助定位。
> ![icon-caution.gif](public_sys-resources/icon-caution.gif) **注意:**
> 开启该功能,节点头多了魔鬼数字字段,会增大节点头大小。由于实时检测完整性,故性能影响较大;若性能敏感的场景,可以不开启该功能,使用LOS_MemIntegrityCheck接口检测。
### 开发指导
#### 开发流程
通过调用LOS_MemIntegrityCheck接口检测内存池是否发生了踩内存,如果没有踩内存问题,那么接口返回0且没有log输出;如果存在踩内存问题,那么会输出相关log,详见下文编程实例的结果输出。
#### 编程实例
本实例实现如下功能:
1.
申请两个物理上连续的内存块;
2.
通过memset构造越界访问,踩到下个节点的头4个字节;
3.
调用LOS_MemIntegrityCheck检测是否发生踩内存。
#### 示例代码
代码实现如下:
```
#include <stdio.h>
#include <string.h>
#include "los_memory.h"
#include "los_config.h"
void MemIntegrityTest(void)
{
/* 申请两个物理连续的内存块 */
void *ptr1 = LOS_MemAlloc(LOSCFG_SYS_HEAP_ADDR, 8);
void *ptr2 = LOS_MemAlloc(LOSCFG_SYS_HEAP_ADDR, 8);
/* 第一个节点内存块大小是8字节,那么12字节的清零,会踩到第二个内存节点的节点头,构造踩内存场景 */
memset(ptr1, 0, 8 + 4);
LOS_MemIntegrityCheck(LOSCFG_SYS_HEAP_ADDR);
}
```
#### 结果验证
编译运行输出log如下:
```
[ERR][OsMemMagicCheckPrint], 2028, memory check error!
memory used but magic num wrong, magic num = 0x00000000 /* 提示信息,检测到哪个字段被破坏了,用例构造了将下个节点的头4个字节清零,即魔鬼数字字段 */
broken node head: 0x20003af0 0x00000000 0x80000020, prev node head: 0x20002ad4 0xabcddcba 0x80000020
/* 被破坏节点和其前节点关键字段信息,分别为其前节点地址、节点的魔鬼数字、节点的sizeAndFlag;可以看出被破坏节点的魔鬼数字字段被清零,符合用例场景 */
broken node head LR info: /* 节点的LR信息需要开启内存检测功能才有有效输出 */
LR[0]:0x0800414e
LR[1]:0x08000cc2
LR[2]:0x00000000
pre node head LR info: /* 通过LR信息,可以在汇编文件中查找前节点是哪里申请,然后排查其使用的准确性 */
LR[0]:0x08004144
LR[1]:0x08000cc2
LR[2]:0x00000000
[ERR]Memory interity check error, cur node: 0x20003b10, pre node: 0x20003af0 /* 被破坏节点和其前节点的地址 */
```
zh-cn/device-dev/kernel/kernel-small-bundles-fs-support.md
浏览文件 @
ed8b2485
# 支持的文件系统
## FAT
### 基本概念
-
**[FAT](kernel-small-bundles-fs-support-fat.md)**
FAT文件系统是File Allocation Table(文件配置表)的简称,主要包括DBR区、FAT区、DATA区三个区域。其中,FAT区各个表项记录存储设备中对应簇的信息,包括簇是否被使用、文件下一个簇的编号、是否文件结尾等。FAT文件系统有FAT12、FAT16、FAT32等多种格式,其中,12、16、32表示对应格式中FAT表项的比特数,它们同时也限制了文件系统中的最大文件大小。FAT文件系统支持多种介质,特别在可移动存储介质(U盘、SD卡、移动硬盘等)上广泛使用,使嵌入式设备和Windows、Linux等桌面系统保持很好的兼容性,方便用户管理操作文件。
-
**[JFFS2](kernel-small-bundles-fs-support-jffs2.md)**
OpenHarmony内核支持FAT12、FAT16与FAT32三种格式的FAT文件系统,具有代码量小、资源占用小、可裁切、支持多种物理介质等特性,并且与Windows、Linux等系统保持兼容,支持多设备、多分区识别等功能。OpenHarmony内核支持硬盘多分区,可以在主分区以及逻辑分区上创建FAT文件系统。
-
**[NFS](kernel-small-bundles-fs-support-nfs.md)**
-
**[Ramfs](kernel-small-bundles-fs-support-ramfs.md)**
### 运行机制
-
**[Procfs](kernel-small-bundles-fs-support-procfs.md)**
\ No newline at end of file
FAT文件系统设计与物理布局的相关文档在互联网上非常丰富,请开发者自行搜索查看。
OpenHarmony LiteOS-A内核通过Bcache提升FAT文件系统性能,Bcache是block cache的简称。当发生读写时,Bcache会缓存读写扇区附近的扇区,以减少I/O次数,提高性能。Bcache的基本缓存单位为block,每个block大小一致(默认有28个block,每个block缓存64个扇区的数据)。当Bcache脏块率(脏扇区数/总扇区数)达到阈值时,会触发写回;如果脏块率未达到阈值,则不会将缓存数据写回磁盘。如果需要保证数据写回,开发者应当调用sync和fsync触发写回。FAT文件系统的部分接口也会触发写回操作(如close、umount等),但开发者不应当基于这些接口触发写回。
### 开发指导
**开发流程**
基本使用流程为挂载→操作→卸载。
SD卡或MMC的设备名为mmcblk[x]p[y],文件系统类型为“vfat”。
示例:
```
mount("/dev/mmcblk0p0", "/mnt", "vfat", 0, NULL);
```
> ![icon-note.gif](public_sys-resources/icon-note.gif) **说明:**
> - FAT文件系统中,单个文件不能大于4 GiB。
>
> - 当有两个SD卡插槽时,卡0和卡1不固定,先插上的为卡0,后插上的为卡1。
>
> - 当多分区功能打开,存在多分区的情况下,卡0注册的设备节点/dev/mmcblk0(主设备)和/dev/mmcblk0p0(次设备)是同一个设备,禁止对主设备进行操作。
>
> - 为避免SD卡使用异常或内存泄漏,SD卡使用过程中拔卡,用户必须先关闭正处于打开状态的文件和目录,并且卸载挂载节点。
>
> - 在format操作之前,需要首先umount挂载点。
>
> - 当Bcache功能生效时,需要注意:
> - 当mount函数的入参为MS_NOSYNC时,FAT不会主动将cache的内容写回存储器件。FAT的如下接口(open、close、 unlink、rename、mkdir、rmdir、truncate)不会自动进行sync操作,速度可以提升,但是需要上层主动调用sync来进行数据同步,否则可能会数据丢失。
>
> - Bcache有定时写回功能。在menuconfig中开启LOSCFG_FS_FAT_CACHE_SYNC_THREAD选项,打开后系统会创建一个任务定时写回Bcache中的数据,默认每隔5秒检查Bcache中脏数据块比例,超过80%时进行sync操作,将Bcache中的脏数据全部写回磁盘。任务优先级、刷新时间间隔以及脏数据块比例的阈值可分别通过接口LOS_SetSyncThreadPrio、 LOS_SetSyncThreadInterval和LOS_SetDirtyRatioThreshold设置。
> - 当前cache的默认大小为28个块,每个块64个扇区。
## JFFS2
### 基本概念
JFFS2是Journalling Flash File System Version 2(日志文件系统)的缩写,是针对MTD设备的日志型文件系统。
OpenHarmony内核的JFFS2主要应用于NOR FLASH闪存,其特点是:可读写、支持数据压缩、提供了崩溃/掉电安全保护、提供“写平衡”支持等。闪存与磁盘介质有许多差异,直接将磁盘文件系统运行在闪存设备上,会导致性能和安全问题。为解决这一问题,需要实现一个特别针对闪存的文件系统,JFFS2就是这样一种文件系统。
### 运行机制
关于JFFS2文件系统的在存储设备上的实际物理布局,及文件系统本身的规格说明,请参考JFFS2的
[
官方规格说明文档
](
https://sourceware.org/jffs2/
)
。
这里仅列举几个对开发者和使用者会有一定影响的JFFS2的重要机制/特征:
1.
Mount机制及速度问题:按照JFFS2的设计,所有的文件会按照一定的规则,切分成大小不等的节点,依次存储到flash设备上。在mount流程中,需要获取到所有的这些节点信息并缓存到内存里。因此,mount速度和flash设备的大小和文件数量的多少成线性比例关系。这是JFFS2的原生设计问题,对于mount速度非常介意的用户,可以在内核编译时开启“Enable JFFS2 SUMMARY”选项,可以极大提升mount的速度。这个选项的原理是将mount需要的信息提前存储到flash上,在mount时读取并解析这块内容,使得mount的速度变得相对恒定。这个实际是空间换时间的做法,会消耗8%左右的额外空间。
2.
写平衡的支持:由于flash设备的物理属性,读写都只能基于某个特定大小的“块”进行,为了防止某些特定的块磨损过于严重,在JFFS2中需要对写入的块进行“平衡”的管理,保证所有的块的写入次数都是相对平均的,进而保证flash设备的整体寿命。
3.
GC(garbage collection)机制:在JFFS2里发生删除动作,实际的物理空间并不会立即释放,而是由独立的GC线程来做空间整理和搬移等GC动作,和所有的GC机制一样,在JFFS2里的GC会对瞬时的读写性能有一定影响。另外,为了有空间能被用来做空间整理,JFFS2会对每个分区预留3块左右的空间,这个空间是用户不可见的。
4.
压缩机制:当前使用的JFFS2,底层会自动的在每次读/写时进行解压/压缩动作,实际IO的大小和用户请求读写的大小并不会一样。特别在写入时,不能通过写入大小来和flash剩余空间的大小来预估写入一定会成功或者失败。
5.
硬链接机制:JFFS2支持硬链接,底层实际占用的物理空间是一份,对于同一个文件的多个硬连接,并不会增加空间的占用;反之,只有当删除了所有的硬链接时,实际物理空间才会被释放。
### 开发指导
对于基于JFFS2和nor flash的开发,总体而言,与其他文件系统非常相似,因为都有VFS层来屏蔽了具体文件系统的差异,对外接口体现也都是标准的POSIX接口。
对于整个裸nor flash设备而言,没有集中的地方来管理和记录分区的信息。因此,需要通过其他的配置方式来传递这部分信息(当前使用的方式是在烧写镜像的时候,使用bootargs参数配置的),然后在代码中调用相应的接口来添加分区,再进行挂载动作。
**制作JFFS2文件系统镜像**
使用mkfs.jffs2工具,制作镜像默认命令如下。页大小默认为4KiB,eraseblock大小默认64KiB。若实际参数与下面不同时,修改相应参数。
```
./mkfs.jffs2 -d rootfs/ -o rootfs.jffs2
```
**表1**
指令含义表(更详细的介绍可以通过mkfs.jffs2 --help来查看)
| 指令 | 含义 |
| -------- | -------- |
| -s | 页大小,不指定默认为4KiB |
| -e | eraseblock大小,不指定默认为64KiB |
| -p | 镜像大小。在镜像文件后面,用0xFF填充至指定大小,不指定则用0xFF填充至eraseblock对齐。 |
| -d | 要制作成文件系统镜像的源目录 |
| -o | 要制成的镜像名称 |
**挂载JFFS2分区**
调用int mount(const char
\*
source, const char
\*
target, const char
\*
filesystemtype, unsigned long mountflags, const void
\*
data)函数实现设备节点和挂载点的挂载。
该函数有五个参数,第一个参数const char
\*
source,表示设备节点,第二个参数const char
\*
target表示挂载点。第三个参数 const char
\*
filesystemtype,表示文件系统类型。
最后两个参数unsigned long mountflags和const void
\*
data表示挂载标志和数据,默认为0和NULL;这一操作也可以在Shell中使用mount命令实现,最后两个参数不需要用户给出。
运行命令:
```
OHOS # mount /dev/spinorblk1 /jffs1 jffs2
```
将从串口得到如下回应信息,表明挂载成功。
```
OHOS # mount /dev/spinorblk1 /jffs1 jffs2
mount OK
```
挂载成功后,用户就能对norflash进行读写操作。
**卸载JFFS2分区**
调用int umount(const char
\*
target)函数卸载分区,只需要正确给出挂载点即可。
运行命令:
```
OHOS # umount /jffs1
```
将从串口得到如下回应信息,表明卸载成功。
```
OHOS # umount /jffs1
umount ok
```
## NFS
### 基本概念
NFS是Network File System(网络文件系统)的缩写。它最大的功能是可以通过网络,让不同的机器、不同的操作系统彼此分享其他用户的文件。因此,用户可以简单地将它看做是一个文件系统服务,在一定程度上相当于Windows环境下的共享文件夹。
### 运行机制
OpenHarmony LiteOS-A内核的NFS文件系统指的是NFS的客户端,NFS客户端能够将远程的NFS服务端分享的目录挂载到本地的机器中,运行程序和共享文件,但不占用当前系统的存储空间,在本地端的机器看起来,远程服务端的目录就好像是自己的一个磁盘一样。
### 开发指导
1.
搭建NFS服务器
这里以Ubuntu操作系统为例,说明服务器端设置步骤。
-
安装NFS服务器软件。
设置好Ubuntu系统的下载源,保证网络连接好的情况下执行:
```
sudo apt-get install nfs-kernel-server
```
-
创建用于挂载的目录并设置完全权限
```
mkdir -p /home/sqbin/nfs
sudo chmod 777 /home/sqbin/nfs
```
-
设置和启动NFS server。
修改NFS配置文件/etc/exports,添加如下一行:
```
/home/sqbin/nfs *(rw,no_root_squash,async)
```
其中/home/sqbin/nfs是NFS共享的根目录。
执行以下命令启动NFS server:
```
sudo /etc/init.d/nfs-kernel-server start
```
执行以下命令重启NFS server:
```
sudo /etc/init.d/nfs-kernel-server restart
```
2.
设置单板为NFS客户端
本指导中的NFS客户端指运行OpenHarmony内核的设备。
-
硬件连接设置。
OpenHarmony内核设备连接到NFS服务器的网络。设置两者IP,使其处于同一网段。比如,设置NFS服务器的IP为10.67.212.178/24,设置OpenHarmony内核设备IP为
10.
67.212.3/24,注意:此IP为内网私有IP地址,用户使用时有差异,以用户实际IP为准。
OpenHarmony内核设备上的IP信息可通过ifconfig命令查看。
-
启动网络,确保单板到NFS服务器之间的网络通畅。
启动以太网或者其他类型网络,使用ping命令检查到服务器的网络是否通畅。
```
OHOS # ping 10.67.212.178
[0]Reply from 10.67.212.178: time=1ms TTL=63
[1]Reply from 10.67.212.178: time=0ms TTL=63
[2]Reply from 10.67.212.178: time=1ms TTL=63
[3]Reply from 10.67.212.178: time=1ms TTL=63
--- 10.67.212.178 ping statistics ---
packets transmitted, 4 received, 0 loss
客户端NFS初始化,运行命令:
```
OHOS # mkdir /nfs
OHOS # mount 10.67.212.178:/home/sqbin/nfs /nfs nfs 1011 1000
```
将从串口得到如下回应信息,表明初始化NFS客户端成功。
```
OHOS # mount 10.67.212.178:/home/sqbin/nfs /nfs nfs 1011 1000
Mount nfs on 10.67.212.178:/home/sqbin/nfs, uid:1011, gid:1000
Mount nfs finished.
```
该命令将服务器10.67.212.178上的/home/sqbin/nfs目录挂载到OpenHarmony内核设备上的/nfs上。
> ![icon-note.gif](public_sys-resources/icon-note.gif) **说明:**
> 本例默认nfs server已经配置可用,即示例中服务器10.67.212.178上的/home/sqbin/nfs已配置可访问。
>
> mount命令的格式为:
>
>
> ```
> mount <SERVER_IP:SERVER_PATH> <CLIENT_PATH> nfs
> ```
>
> 其中“SERVER_IP”表示服务器的IP地址;“SERVER_PATH”表示服务器端NFS共享目录路径;“CLIENT_PATH”表示设备上的NFS路径,“nfs”表示客户端要挂载的路径,可以根据自己需要替换。
>
> 如果不想有NFS访问权限限制,可以在Linux命令行将NFS根目录权限设置成777:
>
>
> ```
> chmod -R 777 /home/sqbin/nfs
> ```
>
> 至此,NFS客户端设置完毕。NFS文件系统已成功挂载。
3.
利用NFS共享文件
在NFS服务器下新建目录dir,并保存。在OpenHarmony内核下运行ls命令:
```
OHOS # ls /nfs
```
则可从串口得到如下回应:
```
OHOS # ls /nfs
Directory /nfs:
drwxr-xr-x 0 u:0 g:0 dir
```
可见,刚刚在NFS服务器上新建的dir目录已同步到客户端(OpenHarmony内核系统)的/nfs目录,两者保持同步。
同样地,在客户端(OpenHarmony内核系统)上创建文件和目录,在NFS服务器上也可以访问,读者可自行体验。
> ![icon-note.gif](public_sys-resources/icon-note.gif) **说明:**
> 目前,NFS客户端仅支持NFS v3部分规范要求,因此对于规范支持不全的服务器,无法完全兼容。在开发测试过程中,建议使用Linux的NFS server,其对NFS支持很完善。
## Ramfs
### 基本概念
RAMFS是一个可动态调整大小的基于RAM的文件系统。RAMFS没有后备存储源。向RAMFS中进行的文件写操作也会分配目录项和页缓存,但是数据并不写回到任何其他存储介质上,掉电后数据丢失。
### 运行机制
RAMFS文件系统把所有的文件都放在 RAM 中,所以读/写操作发生在RAM中,可以用RAMFS来存储一些临时性或经常要修改的数据,例如/tmp和/var目录,这样既避免了对存储器的读写损耗,也提高了数据读写速度。
### 开发指导
挂载:
```
mount(NULL, "/dev/shm", "ramfs", 0, NULL)
```
创建目录:
```
mkdir(pathname, mode)
```
创建文件:
```
open(pathname, O_NONBLOCK | O_CREAT | O_RDWR, mode)
```
读取目录:
```
dir = opendir(pathname)
ptr = readdir(dir)
closedir(dir)
```
删除文件:
```
unlink(pathname)
```
删除目录:
```
rmdir(pathname)
```
去挂载:
```
umount("/dev/shm")
```
> ![icon-caution.gif](public_sys-resources/icon-caution.gif) **注意:**
> - RAMFS只能挂载一次,一次挂载成功后,后面不能继续挂载到其他目录。
>
> - RAMFS属于调测功能,默认配置为关闭,正式产品中不要使用该功能。
## Procfs
### 基本概念
procfs是进程文件系统的简称,是一种虚拟文件系统,他用文件的形式,展示进程或其他系统信息。相比调用接口的方式获取信息,以文件操作的方式获取系统信息更为方便。
### 运行机制
OpenHarmony内核中,procfs在开机时会自动挂载到/proc目录下,仅支持内核模块创建文件节点来提供查询服务。
### 开发指导
procfs文件的创建无法使用一般的文件系统接口,需要使用ProcMkdir接口创建目录,使用CreateProcEntry接口创建文件。文件节点功能的开发就是实现read和write函数的钩子挂到CreateProcEntry创建的文件中。当用户使用读写procfs的文件时,就会调用到钩子函数来实现自定义的功能。
编程实例
下面我们以创建/proc/hello/world文件为例,实现如下功能:
1.
在/proc/hello/world位置创建一个文件
2.
当读文件内容时,返回"HelloWorld!"
3.
当写文件内容时,打印写入的内容
```
#include "proc_fs.h"
static int TestRead(struct SeqBuf *buf, void *arg)
{
LosBufPrintf(buf, "Hello World!\n"); /* 将数据打印到buffer中,这个buffer中的数据会返回到read的结果中 */
return 0;
}
static int TestWrite(struct ProcFile *pf, const char *buffer, size_t buflen, loff_t *ppos)
{
if ((buffer == NULL) || (buflen <= 0)) {
return -EINVAL;
}
PRINTK("your input is: %s\n", buffer); /* 注意和上面的read接口区别,这是对write接口输入命令的反馈,这个打印只会打印到控制台 */
return buflen;
}
static const struct ProcFileOperations HELLO_WORLD_OPS = {
.read = TestRead,
.write = TestWrite,
};
void HelloWorldInit(void)
{
/* 创建hello目录 */
struct ProcDirEntry *dir = ProcMkdir("hello", NULL);
if (dir == NULL) {
PRINT_ERR("create dir failed!\n");
return;
}
/* 创建world文件 */
struct ProcDirEntry *entry = CreateProcEntry("world", 0, dir);
if (entry == NULL) {
PRINT_ERR("create entry failed!\n");
return;
}
/* 将自定义的read和write钩子挂到文件中 */
entry->procFileOps = &HELLO_WORLD_OPS;
}
```
**结果验证**
启动后在shell输入如下命令
```
OHOS # cat /proc/hello/world
OHOS # Hello World!
OHOS # echo "yo" > /proc/hello/world
OHOS # your input is: yo
```
zh-cn/device-dev/kernel/kernel-small-debug-user.md
浏览文件 @
ed8b2485
此差异已折叠。
点击以展开。
zh-cn/device-dev/porting/Readme-CN.md
浏览文件 @
ed8b2485
...
...
@@ -67,3 +67,5 @@ repo init -u https://gitee.com/openharmony-sig/manifest.git -b master -m devboar
-
[
Combo解决方案之W800芯片移植案例
](
porting-w800-combo-demo.md
)
-
小型系统芯片移植案例
-
[
小型设备STM32MP1芯片移植案例
](
porting-stm32mp15xx-on-smallsystem.md
)
-
标准系统芯片移植案例
-
[
标准系统方案之瑞芯微RK3568移植案例
](
porting-dayu200-on_standard-demo.md
)
zh-cn/device-dev/subsystems/Readme-CN.md
浏览文件 @
ed8b2485
...
...
@@ -74,7 +74,13 @@
-
[
设备安全等级管理开发指导
](
subsys-security-devicesecuritylevel.md
)
-
启动恢复
-
[
启动恢复子系统概述
](
subsys-boot-overview.md
)
-
[
init启动引导组件
](
subsys-boot-init.md
)
-
init启动引导组件
-
[
引导启动配置文件
](
subsys-boot-init-cfg.md
)
-
[
jobs管理
](
subsys-boot-init-jobs.md
)
-
[
服务管理
](
subsys-boot-init-service.md
)
-
[
系统参数
](
subsys-boot-init-sysparam.md
)
-
[
沙盒管理
](
subsys-boot-init-sandbox.md
)
-
[
插件
](
subsys-boot-init-plugin.md
)
-
[
appspawn应用孵化组件
](
subsys-boot-appspawn.md
)
-
[
bootstrap服务启动组件
](
subsys-boot-bootstrap.md
)
-
[
常见问题
](
subsys-boot-faqs.md
)
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录