鸿蒙内核源码分析(内存映射篇) | 虚拟内存虚在哪里

最新推荐文章于 2024-08-16 20:46:08 发布
原创 最新推荐文章于 2024-08-16 20:46:08 发布 · 1k 阅读 · 9 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#harmonyos #OpenHarmony #鸿蒙开发 #鸿蒙系统 #鸿蒙

MMU的本质

虚拟地址(VA): 就是线性地址， 鸿蒙内存部分全是VA的身影， 是由编译器和链接器在定位程序时分配的，每个应用程序都使用相同的虚拟内存地址空间，而这些虚拟内存地址空间实际上分别映射到不同的实际物理内存空间上。CPU只知道虚拟地址，向虚拟地址要数据，但在其保护模式下很悲催地址信号在路上被MMU拦截了，MMU把虚拟地址换成了物理地址，从而拿到了真正的数据。

物理地址(PA)：程序的指令和常量数据，全局变量数据以及运行时动态申请内存所分配的实际物理内存存放位置。

MMU采用页表(page table)来实现虚实地址转换，页表项除了描述虚拟页到物理页直接的转换外，还提供了页的访问权限(读，写，可执行)和存储属性。 MMU的本质是拿虚拟地址的高位(20位)做文章，低12位是页内偏移地址不会变。也就是说虚拟地址和物理地址的低12位是一样的，本篇详细讲述MMU是如何变戏法的。

MMU是通过两级页表结构：L1和L2来实现映射功能的，鸿蒙内核当然也实现了这两级页表转换的实现。本篇是系列篇关于内存部分最满意的一篇，也是最不好理解的一篇， 强烈建议结合源码看.

一级页表L1

L1页表将全部的4G地址空间划分为4096个1M的节，页表中每一项(页表项)32位，其内容是L2页表基地址或某个1M物理内存的基地址。虚拟地址的高12位用于对页表项定位，也就是4096个页面项的索引，L1页表的基地址，也叫转换表基地址，存放在CP15的C2（TTB）寄存器中，鸿蒙内核源码分析(内存汇编篇)中有详细的描述，自行翻看。

L1页表项有三种描述格式，鸿蒙源码如下。

/* L1 descriptor type */
#define MMU_DESCRIPTOR_L1_TYPE_INVALID                          (0x0 << 0)
#define MMU_DESCRIPTOR_L1_TYPE_PAGE_TABLE                       (0x1 << 0)
#define MMU_DESCRIPTOR_L1_TYPE_SECTION                          (0x2 << 0)
#define MMU_DESCRIPTOR_L1_TYPE_MASK                             (0x3 << 0)

第一种：Fault（INVALID)页表项，表示对应虚拟地址未被映射，访问将产生一个数据中止异常。

第二种：PAGE_TABLE页表项，指向L2页表的页表项，意思就是把1M分成更多的页（256*4K）

第三种：SECTION页表项 ，指向1M节的页表项的最低二位[1:0]，用于定义页表项的类型，section页表项对应1M的节，直接使用页表项的最高12位替代虚拟地址的高12位即可得到物理地址。还是直接看鸿蒙源码来的清晰，每一行都加了详细的注释。

LOS_ArchMmuQuery
//通过虚拟地址查询物理地址
STATUS_T LOS_ArchMmuQuery(const LosArchMmu *archMmu， VADDR_T vaddr， PADDR_T *paddr， UINT32 *flags)
{//archMmu->virtTtb:转换表基地址
    PTE_T l1Entry = OsGetPte1(archMmu->virtTtb， vaddr);//获取PTE vaddr右移20位 得到L1描述子地址
    PTE_T l2Entry;
    PTE_T* l2Base = NULL;

    if (OsIsPte1Invalid(l1Entry)) {//判断L1描述子地址是否有效
        return LOS_ERRNO_VM_NOT_FOUND;//无效返回虚拟地址未查询到
    } else if (OsIsPte1Section(l1Entry)) {// section页表项: l1Entry低二位是否为 10
        if (paddr != NULL) {//物理地址 = 节基地址(section页表项的高12位) + 虚拟地址低20位
            *paddr = MMU_DESCRIPTOR_L1_SECTION_ADDR(l1Entry) + (vaddr & (MMU_DESCRIPTOR_L1_SMALL_SIZE - 1));
        }

        if (flags != NULL) {
            OsCvtSecAttsToFlags(l1Entry， flags);//获取虚拟内存的flag信息
        }
    } else if (OsIsPte1PageTable(l1Entry)) {//PAGE_TABLE页表项: l1Entry低二位是否为 01
        l2Base = OsGetPte2BasePtr(l1Entry);//获取L2转换表基地址
        if (l2Base == NULL) {
            return LOS_ERRNO_VM_NOT_FOUND;
        }
        l2Entry = OsGetPte2(l2Base， vaddr);//获取L2描述子地址
        if (OsIsPte2SmallPage(l2Entry) || OsIsPte2SmallPageXN(l2Entry)) {
            if (paddr != NULL) {//物理地址 = 小页基地址(L2页表项的高20位) + 虚拟地址低12位
                *paddr = MMU_DESCRIPTOR_L2_SMALL_PAGE_ADDR(l2Entry) + (vaddr & (MMU_DESCRIPTOR_L2_SMALL_SIZE - 1));
            }

            if (flags != NULL) {
                OsCvtPte2AttsToFlags(l1Entry， l2Entry， flags);//获取虚拟内存的flag信息
            }
        } else if (OsIsPte2LargePage(l2Entry)) {//鸿蒙目前暂不支持64K大页，未来手机版应该会支持。
            LOS_Panic("%s %d， large page unimplemented\n"， __FUNCTION__， __LINE__);
        } else {
            return LOS_ERRNO_VM_NOT_FOUND;
        }
    }

    return LOS_OK;
}

这是鸿蒙内核对地址使用最频繁的功能，通过虚拟地址得到物理地址和flag信息，看下哪些地方会调用到它。

二级页表L2

L1页表项表示1M的地址范围，L2把1M分成更多的小页，鸿蒙内核 一页按4K算，所以被分成 256个小页。

L2页表中包含256个页表项，每个32位(4个字节)，L2页表需要 256*4 = 1K的空间，必须按1K对齐，每个L2页表项将4K的虚拟内存地址转换为物理地址，每个L2页面项都给出了一个4K的页基地址。

L2页表项有三种格式：

/* L2 descriptor type */
#define MMU_DESCRIPTOR_L2_TYPE_INVALID                          (0x0 << 0)
#define MMU_DESCRIPTOR_L2_TYPE_LARGE_PAGE                       (0x1 << 0)
#define MMU_DESCRIPTOR_L2_TYPE_SMALL_PAGE                       (0x2 << 0)
#define MMU_DESCRIPTOR_L2_TYPE_SMALL_PAGE_XN                    (0x3 << 0)
#define MMU_DESCRIPTOR_L2_TYPE_MASK                             (0x3 << 0)

第一种：Fault（INVALID)页表项，表示对应虚拟地址未被映射，访问将产生一个数据中止异常。

第二种：大页表项，包含一个指向64K页的指针，但鸿蒙内核并没有实现大页表的支持，给出了未实现的提示

if (OsIsPte2LargePage(l2Entry)) {
            LOS_Panic("%s %d， large page unimplemented\n"， __FUNCTION__， __LINE__);
        }

第三种：小页表项，包含一个指向4K页的指针。
​

映射初始化的过程

先看调用和被调用的关系

//启动映射初始化
VOID OsInitMappingStartUp(VOID)
{
    OsArmInvalidateTlbBarrier();//使TLB失效

    OsSwitchTmpTTB();//切换到临时TTB

    OsSetKSectionAttr();//设置内核段(text，rodata，bss)映射

    OsArchMmuInitPerCPU();//初始化CPU与mmu相关信息
}

干脆利落，调用了四个函数，其中三个在鸿蒙内核源码分析(内存汇编篇)有涉及，不展开讲，这里说OsSetKSectionAttr

它实现了内核空间各个区的映射，内核本身也是程序，鸿蒙把内核空间在物理内存上就独立开来了，也就是说在物理内存上有一段区域是只给内核空间享用的，从根上就把内核和APP 空间隔离了，里面放的是内核的重要数据(包括代码，常量和全局变量)，具体看代码，代码很长，整个函数全贴出来了，都加上了注释。

OsSetKSectionAttr 内核空间的设置和映射
typedef struct ArchMmuInitMapping {
    PADDR_T phys;//物理地址
    VADDR_T virt;//虚拟地址
    size_t  size;//大小
    unsigned int flags;//标识 读/写/.. VM_MAP_REGION_FLAG_PERM_*
    const char *name;//名称
} LosArchMmuInitMapping;

VADDR_T *OsGFirstTableGet()
{
    return (VADDR_T *)g_firstPageTable;//UINT8 g_firstPageTable[MMU_DESCRIPTOR_L1_SMALL_ENTRY_NUMBERS]
}
//设置内核空间段属性，可看出内核空间是固定映射到物理地址
STATIC VOID OsSetKSectionAttr(VOID)
{
    /* every section should be page aligned */
    UINTPTR textStart = (UINTPTR)&__text_start;//代码段开始位置
    UINTPTR textEnd = (UINTPTR)&__text_end;//代码段结束位置
    UINTPTR rodataStart = (UINTPTR)&__rodata_start;//常量只读段开始位置
    UINTPTR rodataEnd = (UINTPTR)&__rodata_end;//常量只读段结束位置
    UINTPTR ramDataStart = (UINTPTR)&__ram_data_start;//全局变量段开始位置
    UINTPTR bssEnd = (UINTPTR)&__bss_end;//bss结束位置
    UINT32 bssEndBoundary = ROUNDUP(bssEnd， MB);
    LosArchMmuInitMapping mmuKernelMappings[] = {
        {
            .phys = SYS_MEM_BASE + textStart - KERNEL_VMM_BASE，//映射物理内存位置
            .virt = textStart，//内核代码区
            .size = ROUNDUP(textEnd - textStart， MMU_DESCRIPTOR_L2_SMALL_SIZE)，//代码区大小
            .flags = VM_MAP_REGION_FLAG_PERM_READ | VM_MAP_REGION_FLAG_PERM_EXECUTE，//代码段可读，可执行
            .name = "kernel_text"
        }，
        {
            .phys = SYS_MEM_BASE + rodataStart - KERNEL_VMM_BASE，//映射物理内存位置
            .virt = rodataStart，//内核常量区
            .size = ROUNDUP(rodataEnd - rodataStart， MMU_DESCRIPTOR_L2_SMALL_SIZE)，//4K对齐
            .flags = VM_MAP_REGION_FLAG_PERM_READ，//常量段只读
            .name = "kernel_rodata"
        }，
        {
            .phys = SYS_MEM_BASE + ramDataStart - KERNEL_VMM_BASE，//映射物理内存位置
            .virt = ramDataStart，
            .size = ROUNDUP(bssEndBoundary - ramDataStart， MMU_DESCRIPTOR_L2_SMALL_SIZE)，
            .flags = VM_MAP_REGION_FLAG_PERM_READ | VM_MAP_REGION_FLAG_PERM_WRITE，//全局变量区可读可写
            .name = "kernel_data_bss"
        }
    };
    LosVmSpace *kSpace = LOS_GetKVmSpace();//获取内核空间
    status_t status;
    UINT32 length;
    paddr_t oldTtPhyBase;
    int i;
    LosArchMmuInitMapping *kernelMap = NULL;//内核映射
    UINT32 kmallocLength;

    /* use second-level mapping of default READ and WRITE */
    kSpace->archMmu.virtTtb = (PTE_T *)g_firstPageTable;//__attribute__((section(".bss.prebss.translation_table"))) UINT8 g_firstPageTable[MMU_DESCRIPTOR_L1_SMALL_ENTRY_NUMBERS];
    kSpace->archMmu.physTtb = LOS_PaddrQuery(kSpace->archMmu.virtTtb);//通过TTB虚拟地址查询TTB物理地址
    status = LOS_ArchMmuUnmap(&kSpace->archMmu， KERNEL_VMM_BASE，
                               (bssEndBoundary - KERNEL_VMM_BASE) >> MMU_DESCRIPTOR_L2_SMALL_SHIFT);//解绑 bssEndBoundary - KERNEL_VMM_BASE 映射
    if (status != ((bssEndBoundary - KERNEL_VMM_BASE) >> MMU_DESCRIPTOR_L2_SMALL_SHIFT)) {//解绑失败
        VM_ERR("unmap failed， status: %d"， status);
        return;
    }
 //映射 textStart - KERNEL_VMM_BASE 区
    status = LOS_ArchMmuMap(&kSpace->archMmu， KERNEL_VMM_BASE， SYS_MEM_BASE，
                             (textStart - KERNEL_VMM_BASE) >> MMU_DESCRIPTOR_L2_SMALL_SHIFT，
                             VM_MAP_REGION_FLAG_PERM_READ | VM_MAP_REGION_FLAG_PERM_WRITE |
                             VM_MAP_REGION_FLAG_PERM_EXECUTE);
    if (status != ((textStart - KERNEL_VMM_BASE) >> MMU_DESCRIPTOR_L2_SMALL_SHIFT)) {
        VM_ERR("mmap failed， status: %d"， status);
        return;
    }

    length = sizeof(mmuKernelMappings) / sizeof(LosArchMmuInitMapping);
    for (i = 0; i < length; i++) {//对mmuKernelMappings一一映射好
        kernelMap = &mmuKernelMappings[i];
        status = LOS_ArchMmuMap(&kSpace->archMmu， kernelMap->virt， kernelMap->phys，
                                 kernelMap->size >> MMU_DESCRIPTOR_L2_SMALL_SHIFT， kernelMap->flags);
        if (status != (kernelMap->size >> MMU_DESCRIPTOR_L2_SMALL_SHIFT)) {
            VM_ERR("mmap failed， status: %d"， status);
            return;
        }
        LOS_VmSpaceReserve(kSpace， kernelMap->size， kernelMap->virt);//保留区
    }
 //将剩余空间映射好
    kmallocLength = KERNEL_VMM_BASE + SYS_MEM_SIZE_DEFAULT - bssEndBoundary;
    status = LOS_ArchMmuMap(&kSpace->archMmu， bssEndBoundary，
                             SYS_MEM_BASE + bssEndBoundary - KERNEL_VMM_BASE，
                             kmallocLength >> MMU_DESCRIPTOR_L2_SMALL_SHIFT，
                             VM_MAP_REGION_FLAG_PERM_READ | VM_MAP_REGION_FLAG_PERM_WRITE);
    if (status != (kmallocLength >> MMU_DESCRIPTOR_L2_SMALL_SHIFT)) {
        VM_ERR("unmap failed， status: %d"， status);
        return;
    }
    LOS_VmSpaceReserve(kSpace， kmallocLength， bssEndBoundary);

    /* we need free tmp ttbase */
    oldTtPhyBase = OsArmReadTtbr0();//读取TTB值
    oldTtPhyBase = oldTtPhyBase & MMU_DESCRIPTOR_L2_SMALL_FRAME;
    OsArmWriteTtbr0(kSpace->archMmu.physTtb | MMU_TTBRx_FLAGS);//内核页表基地址写入CP15 c2(TTB寄存器)
    ISB;

    /* we changed page table entry， so we need to clean TLB here */
    OsCleanTLB();//清空TLB缓冲区

    (VOID)LOS_MemFree(m_aucSysMem0， (VOID *)(UINTPTR)(oldTtPhyBase - SYS_MEM_BASE + KERNEL_VMM_BASE));//释放内存池
}

LOS_ArchMmuMap

mmu的map 就是生成L1，L2页表项的过程，以供虚实地址的转换使用，还是直接看代码吧，代码说明一切！

//所谓的 map 就是 生成L1，L2页表项的过程
status_t LOS_ArchMmuMap(LosArchMmu *archMmu， VADDR_T vaddr， PADDR_T paddr， size_t count， UINT32 flags)
{
    PTE_T l1Entry;
    UINT32 saveCounts = 0;
    INT32 mapped = 0;
    INT32 checkRst;

    checkRst = OsMapParamCheck(flags， vaddr， paddr);//检查参数
    if (checkRst < 0) {
        return checkRst;
    }

    /* see what kind of mapping we can use */
    while (count > 0) {
        if (MMU_DESCRIPTOR_IS_L1_SIZE_ALIGNED(vaddr) && //虚拟地址和物理地址对齐 0x100000（1M）时采用
            MMU_DESCRIPTOR_IS_L1_SIZE_ALIGNED(paddr) && //section页表项格式
            count >= MMU_DESCRIPTOR_L2_NUMBERS_PER_L1) { //MMU_DESCRIPTOR_L2_NUMBERS_PER_L1 = 0x100 
            /* compute the arch flags for L1 sections cache， r ，w ，x， domain and type */
            saveCounts = OsMapSection(archMmu， flags， &vaddr， &paddr， &count);//生成L1 section类型页表项并保存
        } else {
            /* have to use a L2 mapping， we only allocate 4KB for L1， support 0 ~ 1GB */
            l1Entry = OsGetPte1(archMmu->virtTtb， vaddr);//获取L1页面项
            if (OsIsPte1Invalid(l1Entry)) {//L1 fault页面项类型
                OsMapL1PTE(archMmu， &l1Entry， vaddr， flags);//生成L1 page table类型页表项并保存
                saveCounts = OsMapL2PageContinous(l1Entry， flags， &vaddr， &paddr， &count);//生成L2 页表项目并保存
            } else if (OsIsPte1PageTable(l1Entry)) {//L1 page table页面项类型
                saveCounts = OsMapL2PageContinous(l1Entry， flags， &vaddr， &paddr， &count);//生成L2 页表项目并保存
            } else {
                LOS_Panic("%s %d， unimplemented tt_entry %x\n"， __FUNCTION__， __LINE__， l1Entry);
            }
        }
        mapped += saveCounts;
    }

    return mapped;
}

STATIC UINT32 OsMapL2PageContinous(PTE_T pte1， UINT32 flags， VADDR_T *vaddr， PADDR_T *paddr， UINT32 *count)
{
    PTE_T *pte2BasePtr = NULL;
    UINT32 archFlags;
    UINT32 saveCounts;

    pte2BasePtr = OsGetPte2BasePtr(pte1);
    if (pte2BasePtr == NULL) {
        LOS_Panic("%s %d， pte1 %#x error\n"， __FUNCTION__， __LINE__， pte1);
    }

    /* compute the arch flags for L2 4K pages */
    archFlags = OsCvtPte2FlagsToAttrs(flags);
    saveCounts = OsSavePte2Continuous(pte2BasePtr， OsGetPte2Index(*vaddr)， *paddr | archFlags， *count);
    *paddr += (saveCounts << MMU_DESCRIPTOR_L2_SMALL_SHIFT);
    *vaddr += (saveCounts << MMU_DESCRIPTOR_L2_SMALL_SHIFT);
    *count -= saveCounts;
    return saveCounts;
}

OsMapL2PageContinous 没有加注释，希望你别太懒，赶紧动起来，到这里应该都能看懂了！最好能结合 鸿蒙内核源码分析(内存汇编篇)一起看理解会更深透。

为了能让大家更好的学习鸿蒙（HarmonyOS NEXT）开发技术，这边特意整理了《鸿蒙开发学习手册》（共计890页），希望对大家有所帮助：https://qr21.cn/FV7h05

《鸿蒙开发学习手册》：

如何快速入门：https://qr21.cn/FV7h05

  1. 基本概念
  2. 构建第一个ArkTS应用
  3. ……

开发基础知识：https://qr21.cn/FV7h05

  1. 应用基础知识
  2. 配置文件
  3. 应用数据管理
  4. 应用安全管理
  5. 应用隐私保护
  6. 三方应用调用管控机制
  7. 资源分类与访问
  8. 学习ArkTS语言
  9. ……

基于ArkTS 开发：https://qr21.cn/FV7h05

  1. Ability开发
  2. UI开发
  3. 公共事件与通知
  4. 窗口管理
  5. 媒体
  6. 安全
  7. 网络与链接
  8. 电话服务
  9. 数据管理
  10. 后台任务(Background Task)管理
  11. 设备管理
  12. 设备使用信息统计
  13. DFX
  14. 国际化开发
  15. 折叠屏系列
  16. ……

鸿蒙开发面试真题（含参考答案）：https://qr18.cn/F781PH

鸿蒙开发面试大盘集篇（共计319页）：https://qr18.cn/F781PH

1.项目开发必备面试题
2.性能优化方向
3.架构方向
4.鸿蒙开发系统底层方向
5.鸿蒙音视频开发方向
6.鸿蒙车载开发方向
7.鸿蒙南向开发方向

v15.03 鸿蒙内核源码分析(内存映射) | 映射真是个好东西 | 百篇博客分析HarmonyOS源码
日拱一卒，力出一孔
10-30 1万+
提示：本文为鸿蒙生态源码分析总目录，源码来自官方源码库【OpenHarmony】，项目来自【开放原子开源基金会】 本文作者：鸿蒙生态发烧友，将持续研究鸿蒙生态源码，更新博文，敬请关注。内容仅代表个人观点，错误之处，欢迎大家指正完善。 2020年9月11号，华为正式发布鸿蒙生态源码，共涉及100多个仓库，笔者 git clone的那一刻内心还是有点小激动的，仿佛回到了大学期间花了一学期废寝忘食硬啃Linux 0.11源码的那段日子。分析鸿蒙内核源码，每天都有新的体会，于是有了一个想法，把分析的过程...
v08.03 鸿蒙源码分析系列(总目录) | 百万汉字注解 百篇博客分析 | 热爱是所有的理由和答案
热门推荐
日拱一卒，力出一孔
09-22 3万+
提示：本文为鸿蒙系统源码分析总目录，源码来自官方源码库【OpenHarmony】，项目来自【开放原子开源基金会】 本文作者：鸿蒙生态发烧友，将持续研究鸿蒙系统源码，敬请关注。内容仅代表个人观点，错误之处，欢迎大家指正完善。 鸿蒙系统源码分析 鸿蒙内核源码分析 官方源码【kernel_liteos_a】官方文档【docs】参考文档【Huawei LiteOS】 鸿蒙内核源码分析(双向循环链表篇) ...
鸿蒙内核源码分析(编译过程篇) | 简单案例窥视编译全过程
m0_70748458的博客
06-26 1360
一个.c源文件编译的整个过程如图.
鸿蒙源码分析（六十五）
安辰的博客
10-21 738
任务or线程？ 经过分析take_manager代码，我们发现任务的出现常常伴随着线程，任务池的工作和线程的工作原理有一定的相似度，我们今天分析一下这两者的区别。 鸿蒙中任务就是一种线程，二者本质上没有区别，只是在不同的应用环境下有不一样的名字 下面附上任务的定义代码 typedef struct { VOID *stackPointer; /**< Task stack pointer */ //内核态栈指针，SP位置，切换任务时先保存上下文并指向TaskCo
鸿蒙源码分析（五十一）
安辰的博客
09-13 407
hks_storage.c 代码及其头文件分析 由于本片代码篇幅过长，这里分多篇博客分析。该文件主要涉及内存中密钥的信息、状态、和一些算法的设置。 文件路径 头文件 头文件主要是一些函数的声明、变量的宏定义以及部分结构体的说明。设计密钥在内存中的存放和数据的缓冲区定义 #define HKS_KEY_INFO_RESERVE_NUMBER 2 //密钥信息保存的组数 #define HKS_LOCAL_STORAGE_KEY_MAX_NUM 20 //本地密钥保存的最大数量 #def
鸿蒙内核源码分析(内存管理篇) | 虚拟内存全景图是怎样的
maniuT的博客
04-28 1132
所有的用户进程都是通过init进程 fork来的， 可以看到创建进程的同时创建了一个task， 入口函数就是代码区的第一条指令，也就是应用程序 main函数。进程的主体是来自进程池，进程池是统一分配的，怎么创建进程池的去翻系列篇里的文章，所以创建一个进程的时候只需要分配虚拟内存LosVmSpace，这里要分内核模式和用户模式下的申请。细心的读者可能发现了，鸿蒙内核几乎所有的全局变量都没有赋初始化值或NULL，这些变量经过编译后是放在了BSS段的，运行时占用内存空间，如此编译出来的ELF包就变小了。
鸿蒙内核源码分析(内存汇编篇) | 谁是虚拟内存实现的基础
最新发布
鸿蒙开发知识记录
08-16 793
ARM处理器使用协处理器15(CP15)的寄存器来控制cache、TCM和存储器管理。CP15的寄存器只能被MRC和MCR（Move to Coprocessor from ARM Register ）指令访问，包含16个32位的寄存器，其编号为0~15。本篇重点讲解其中的 C7，C2，C13三个寄存器。
鸿蒙源码分析（六十三）
安辰的博客
10-15 680
message.c分析 相关知识 代码部分 Provides message communication APIs that help you to implement asynchronous functions
鸿蒙源码分析（三十）
安辰的博客
08-14 389
hks_crypto_ed25519.c代码分析 一、背景知识 ed25519算法介绍 二、代码分析 定义相关变量，定义公钥和私钥的字节数 #define CRYPTO_SUCCESS 1 //存放返回值表示加密成功 #define ED25519_PRIVATE_KEY_LEN 32 //私钥字节数32 #define ED25519_PUBLIC_KEY_LEN 32 //公钥字节数32 密钥信息保存 实现公钥私钥数据的复制保存。 参数详解： pubKey：传入存放公钥数据的结构体 prikey
鸿蒙内核源码分析(百篇博客分析）.pdf
09-23
鸿蒙内核源码分析(百篇博客分析）鸿蒙内核源码分析(编译过程篇)|简单案例窥视GCC编译全过程
鸿蒙源码解析（一）
安辰的博客
07-26 4161
鸿蒙模块一trans_service目录下auth_conn_manager.c和auth_conn_manager.h文件解析 其中trans_service目录主要负责设备的身份验证和传输通道，提供设备认证机制。而auth机制在设备认证和用户权限验证中发挥着重要的作用。 auth机制原理图一 auth机制原理图二 auth机制是一个开放标准，允许用户授权第三方移动应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方移动应用或分享他们数据的所有内容。 使用场景： 用户
鸿蒙源码分析（二十）
安辰的博客
08-09 599
鸿蒙安全模块当中的RSA加密算法 RSA加密是现代安全算法当中常用的加密算法，
鸿蒙源码分析（六十九）
安辰的博客
10-30 545
service剩下函数分析 我们知道该模块下经常出现的任务概念，这里我们也可以理解为消息。这里有消息的处理函数。 任务或者消息通过iunknown接口发送，这个函数就是默认的处理该接口发送过来的消息。先根据参数identity来判断身份是否合法。如果合法调用相应的函数来处理消息。其中还需要判断是service还是feature，根据不同情况调用不同处理函数。 参数参数： serviceImpl：服务实例 identity：身份信息标识 msg：消息数据 void DEFAULT_MessageHandl
鸿蒙源码分析（五十）
安辰的博客
09-06 295
pub_sub_feature.c代码分析 该文件主要功能 文件路径 一、背景知识 1.结构体和宏定义 消费节点结构体 typedef struct ConsumerNode { UTILS_DL_LIST node; Consumer *consumer; } ConsumerNode; 关系结构体 typedef struct Relation { UTILS_DL_LIST node; //节点 ConsumerNode callbacks; ///回调的消费节点
鸿蒙源码分析（十三）
安辰的博客
08-05 2217
软总线模块中trans_service目录分析总结 本文主要总结软总线模块下trans_service目录中个文件的作用和功能，宏观上把握trans_service在鸿蒙系统中发挥的作用。 一、分布式软总线介绍 1.1 总线 总线（Bus）是一个非常广泛的概念，在传统计算机硬件体系中应用的非常广泛。它是一种内部结构，是cpu、内存、输入、输出设备传递信息的公用通道，主机的各个部件通过总线相连接，外部设备通过相应的接口电路再与总线相连接，从而形成了计算机硬件系统。在计算机系统中，各个部件之间传送信息的公共通路
v54.04 鸿蒙内核源码分析(静态链接) | 一个小项目看中间过程 | 百篇博客分析HarmonyOS源码
日拱一卒，力出一孔
05-15 668
将 HarmonyOS | 鸿蒙 研究到底 < 国内 | 国外 > 百篇博客系列篇.本篇为: v54.xx 鸿蒙内核源码分析(静态链接篇) | 完整小项目看透静态链接过程 | 51 .c .h .o 下图是一个可执行文件编译,链接的过程. 本篇将通过一个完整的小工程来阐述ELF编译,链接过程,并分析.o和bin文件中各区,符号表之间的关系.从一个崭新的视角去看中间过程,阅读之前建议先看 v53.xx 鸿蒙内核源码分析(ELF解析篇) | 你要忘了她姐俩你就不是银 |
剖析鸿蒙内核源码
weixin_45356954的博客
12-12 2130
先看大佬们对其的定义vnode 是内核内存中的一个对象，它使用 UNIX 文件接口（打开、读取、写入、关闭、readdir 等）。Vnodes 可以代表文件、目录、管道、套接字、块设备、字符设备。vnode -- 文件或目录的内部表示. vnode 是 UNIX 中所有文件活动的焦点。vnode 由 struct vnode 描述。为每个活动文件、每个当前目录、每个挂载文件、文本文件和根分配了一个唯一的 vnode。
Linux内核源码分析：物理内存管理及虚拟内存管理实践
Linux内核源代码分析中，重要的一部分是对物理内存管理的理解和分析。物理内存是操作系统内核和用户程序运行的基础，因为处理器需要不断地从内存中取指令、取数据，并将计算结果保存至内存。同时，内核和用户程序的...
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值