ELF结构体注解

    百万汉字注解 + 百篇博客分析 => 挖透鸿蒙内核源码
    https://my.oschina.net/weharmony

README.md

@@ -15,27 +15,27 @@
   
 ### **为何要精读内核源码?**
 
-* 在每位码农的学职生涯,都应精读一遍内核源码.以浇筑好计算机知识大厦的地基，地基纵深的坚固程度，很大程度能决定了未来大厦能盖多高。为何一定要精读细品呢?
+* 每位码农的学职生涯,都应精读一遍内核源码.以浇筑好计算机知识大厦的地基，地基纵深的坚固程度，很大程度能决定未来大厦能盖多高。那为何一定要精读细品呢?
   
-* 因为内核代码本身并不太多，都是浓缩的精华，精读是让各个知识点高频出现，不孤立成点状记忆,让各点相连成线,线线成面,刻意练习,闪爆大脑，如此短时间内容易结成一张高浓度，高密度的底层网，内核画面越描越清晰,越雕越深刻,不断训练大脑肌肉记忆,将记忆从临时区转移到永久区。跟骑单车一样，一旦学会，即便多年不骑，照样跨上就走，游刃有余。
+* 因为内核代码本身并不太多，都是浓缩的精华，精读是让各个知识点高频出现，不孤立成点状记忆,让各点相连成线,线面成体,刻意练习,闪爆大脑，如此短时间内容易结成一张高浓度，高密度的底层网，内核画面越描越清晰,越雕越深刻,不断训练大脑肌肉记忆,将记忆从临时区转移到永久区。跟骑单车一样，一旦学会，即便多年不骑，照样跨上就走，游刃有余。
 
 ### **热爱是所有的理由和答案**
 
-* 因大学时阅读 `linux 2.6` 内核痛并快乐的经历,一直有个心愿,如何让更多对内核感兴趣的朋友减少阅读时间,加速对计算机系统级的理解,而不至于过早的放弃.但因过程种种,多年一直没有行动,基本要放弃这件事了. 恰逢 **2020/9/10** 鸿蒙正式开源,重新激活了多年的心愿,就有那么点一发不可收拾了. 
+* 因大学时阅读 `linux 2.6` 内核痛并快乐的经历,一直有个心愿,如何让更多对内核感兴趣的朋友减少阅读时间,加速对计算机系统级的理解,而不至于过早的放弃.但因过程种种,多年一直没有行动,基本要放弃这件事了.恰逢 **2020/9/10** 鸿蒙正式开源,重新激活了多年的心愿,就有那么点一发不可收拾了. 
   
 * 到 **2021/3/10** 刚好半年, 对内核源码的注解已完成了 **70%** ,对内核源码的博客分析已完成了**40篇**, 每天都很充实,很兴奋,连做梦内核代码都在往脑海里鱼贯而入.如此疯狂地做一件事还是当年谈恋爱的时候, 只因热爱, 热爱是所有的理由和答案. :P 
 
 ### **(〃･ิ‿･ิ)ゞ鸿蒙内核开发者**
 
-* 感谢开放原子开源基金会,致敬鸿蒙内核开发者提供了如此优秀的源码,一了多年的夙愿,津津乐道于此.精读内核源码当然是件很困难的事,时间上要以月甚至年为单位,但正因为很难才值得去做! 干困难事,必有所得. 专注聚焦,必有所获. 
+* 感谢开放原子开源基金会,致敬鸿蒙内核开发者提供了如此优秀的源码,一了多年的夙愿,津津乐道于此.精读内核源码加注并整理成档是件很有挑战的事,时间上要以月甚至年为单位,但正因为很难才值得去做! 干困难事,方有所得;专注聚焦,必有所获. 
 
-* 从内核一行行的代码中能深深感受到开发者各中艰辛与坚持,及鸿蒙生态对未来的价值,这些是张嘴就来的网络喷子们永远不能体会到的.可以毫不夸张的说鸿蒙内核源码可作为大学 **C语言**,**数据结构**,**操作系统**,**汇编语言**,**计算机组成原理** 五门课程的教学项目.如此宝库,不深入研究实在是暴殄天物,于心不忍,注者坚信鸿蒙大势所趋,未来可期,它必须成功,也必然成功,誓做其坚定的追随者和传播者.
+* 从内核一行行的代码中能深深感受到开发者各中艰辛与坚持,及鸿蒙生态对未来的价值,这些是张嘴就来的网络喷子们永远不能体会到的.可以毫不夸张的说鸿蒙内核源码可作为大学 **C语言**,**数据结构**,**操作系统**,**汇编语言**,**计算机组成原理** 五门课程的教学项目.如此宝库,不深入研究实在是暴殄天物,于心不忍,注者坚信鸿蒙大势所趋,未来可期,其必须成功,也必然成功,誓做其坚定的追随者和传播者.
 
 ### **加注方式是怎样的？**
 
-*  因鸿蒙内核6W+代码量,本身只有较少的注释, 中文注解以不对原有代码侵入为前提,源码中所有英文部分都是原有注释,所有中文部分都是中文版的注释,尽量不去增加代码的行数,不破坏文件的结构,试图把知识讲透彻,注释多类似以下的方式:
+*  因鸿蒙内核6W+代码量,本身只有较少的注释, 中文注解以不对原有代码侵入为前提,源码中所有英文部分都是原有注释,所有中文部分都是中文版的注释,同时为方便同步官方版本的更新,尽量不去增加代码的行数,不破坏文件的结构,注释多类似以下的方式:
 
-    在重要模块的.c文件开始位置先对模块功能做整体的介绍,例如异常接管模块注解如图所示:
+    在重要模块的.c/.h文件开始位置先对模块功能做整体的介绍,例如异常接管模块注解如图所示:
 
     ![在这里插入图片描述](https://gitee.com/weharmony/docs/raw/master/pic/other/ycjg.png)
 
@@ -53,9 +53,9 @@
 
 注者认为理解内核可分三个层级:
 
-* **普通概念映射级:** 这一级不涉及专业知识,用大众所熟知的公共认知就能听明白是个什么概念,也就是说用一个普通人都懂的概念去诠释或者映射一个他们从没听过的概念.让陌生的知识点与大脑中烂熟于心的知识点建立多重链接,加深记忆.说别人能听得懂的话这很重要!!! 一个没学过计算机知识的卖菜大妈就不可能知道内核的基本运作了吗? 不一定!,在系列篇中试图用 **[鸿蒙内核源码分析(总目录)之故事篇](https://my.oschina.net/weharmony)** 去引导这一层级的认知,希望能卷入更多的人来关注基础软件,尤其是那些资本大鳄,加大对基础软件的投入.
+* **普通概念映射级:** 这一级不涉及专业知识,用大众所熟知的公共认知就能听明白是个什么概念,也就是说用一个普通人都懂的概念去诠释或者映射一个他们从没听过的概念.让陌生的知识点与大脑中烂熟于心的知识点建立多重链接,加深记忆.说别人能听得懂的话这很重要!!! 一个没学过计算机知识的卖菜大妈就不可能知道内核的基本运作了吗? 不一定!在系列篇中试图用 **[鸿蒙内核源码分析(总目录)之故事篇](https://my.oschina.net/weharmony)** 去引导这一层级的认知,希望能卷入更多的人来关注基础软件,尤其是那些资本大鳄,加大对基础软件的投入.
 
-* **专业概念抽象级:** 对抽象的专业逻辑概念具体化认知, 比如虚拟内存,老百姓是听不懂的,学过计算机的人都懂,具体怎么实现的很多人又都不懂了,但这并不妨碍成为一个优秀的上层应用程序员,因为虚拟内存已经被抽象出来,目的是要屏蔽上层对它具体实现的认知.试图用 **[鸿蒙内核源码分析(总目录)百篇博客](https://my.oschina.net/weharmony)** 去拆解那些已经被抽象出来的专业概念, 希望能卷入更多对内核感兴趣的应用软件人才流入基础软件生态, 应用软件咱们是无敌宇宙,但基础软件却很薄弱.
+* **专业概念抽象级:** 对抽象的专业逻辑概念具体化认知, 比如虚拟内存,老百姓是听不懂的,学过计算机的人都懂,具体怎么实现的很多人又都不懂了,但这并不妨碍成为一个优秀的上层应用开发者,因为虚拟内存已经被抽象出来,目的是要屏蔽上层对它具体实现的认知.试图用 **[鸿蒙内核源码分析(总目录)百篇博客](https://my.oschina.net/weharmony)** 去拆解那些已经被抽象出来的专业概念, 希望能卷入更多对内核感兴趣的应用软件人才流入基础软件生态, 应用软件咱们是无敌宇宙,但基础软件却很薄弱.
 
 * **具体微观代码级:** 这一级是具体到每一行代码的实现,到了用代码指令级的地步,这段代码是什么意思?为什么要这么设计?有没有更好的方案? **[鸿蒙内核源码注解分析](https://gitee.com/weharmony/kernel_liteos_a_note)** 试图从细微处去解释代码实现层,英文真的是天生适合设计成编程语言的人类语言,计算机的01码映射到人类世界的26个字母,诞生了太多的伟大奇迹.但我们的母语注定了很大部分人存在着自然语言层级的理解映射,希望鸿蒙内核源码注解分析能让更多爱好者快速的理解内核,共同进步.
 ## 百篇博客分析
@@ -192,16 +192,8 @@
 
 * 中文加注版比官方版无新增文件,只多了一个zzz的目录,里面放了一些文件,它与内核代码无关,大家可以忽略它,取名zzz是为了排在最后,减少对原有代码目录级的侵入,zzz的想法源于微信中名称为AAA的那帮朋友,你的微信里应该也有他们熟悉的身影吧 :|P
 
-### 参与贡献
+### 两句话
 
-* [访问注解仓库地址](https://gitee.com/weharmony/kernel_liteos_a_note)
+* [热爱是所有的理由和答案 - turing](https://weharmony.gitee.io/)
 
-* [Fork 本仓库](https://gitee.com/weharmony/kernel_liteos_a_note) >> 新建 Feat_xxx 分支 >> 提交代码注解 >> [新建 Pull Request](https://gitee.com/weharmony/kernel_liteos_a_note/pull/new/weharmony:master...weharmony:master)
-
-* [新建 Issue](https://gitee.com/weharmony/kernel_liteos_a_note/issues)
-
-### 喜欢请「点赞+关注+收藏」
-
-* [![鸿蒙内核源码分析](https://gitee.com/weharmony/docs/raw/master/pic/other/so1so.png)](https://gitee.com/weharmony/docs/raw/master/pic/other/so1so.png)
-
-* 各大站点搜 **「鸿蒙内核源码分析」**.欢迎转载,请注明出处.
+* [不经过深度思考的人生不值得一过 - turing](https://gitee.com/weharmony/docs/raw/master/pic/other/so1so.png)
\ No newline at end of file

kernel/extended/dynload/include/los_ld_elf_pri.h

@@ -44,23 +44,24 @@ extern "C" {
 #define LD_EI_NIDENT           16
 
 typedef struct {
-    UINT8       elfIdent[LD_EI_NIDENT]; /* Magic number and other info *///含前16个字节，又可细分成class、data、version等字段，具体含义不用太关心，只需知道前4个字节点包含”ELF”关键字，这样可以判断当前文件是否是ELF格式；
-    UINT16      elfType;                /* Object file type *///表示具体ELF类型，可重定位文件/可执行文件/共享库文件，显然这里是一个可执行文件；e_machine表示执行的机器平台，这里是x86_64；
+    UINT8       elfIdent[LD_EI_NIDENT]; /* Magic number and other info *///含前16个字节，又可细分成class、data、version等字段，具体含义不用太关心，只需知道前4个字节点包含`ELF`关键字，这样可以判断当前文件是否是ELF格式
+    UINT16      elfType;                /* Object file type *///表示具体ELF类型，可重定位文件/可执行文件/共享库文件
     UINT16      elfMachine;             /* Architecture *///表示cpu架构
-    UINT32      elfVersion;             /* Object file version *///表示文件版本号，这里的1表示初始版本号；
-    UINT32      elfEntry;               /* Entry point virtual address *///对应”Entry point address”，程序入口函数地址，通过进程虚拟地址空间地址(0x400440)表达；
-    UINT32      elfPhoff;               /* Program header table file offset *///对应“Start of program headers”，表示program header table在文件内的偏移位置，这里是从第64号字节(假设初始为0号字节)开始；
-    UINT32      elfShoff;               /* Section header table file offset *///对应”Start of section headers”，表示section header table在文件内的偏移位置，这里是从第4472号字节开始，靠近文件尾部；
-    UINT32      elfFlags;               /* Processor-specific flags *///表示与CPU处理器架构相关的信息，这里为零；
-    UINT16      elfHeadSize;            /* ELF header size in bytes *///对应”Size of this header”，表示本ELF header自身的长度，这里为64个字节，回看前面的e_phoff为64，说明ELF header后紧跟着program header table；
-    UINT16      elfPhEntSize;           /* Program header table entry size *///对应“Size of program headers”，表示program header table中每个元素的大小，这里为56个字节；
-    UINT16      elfPhNum;               /* Program header table entry count *///对应”Number of program headers”，表示program header table中元素个数，这里为9个；
-    UINT16      elfShEntSize;           /* Section header table entry size *///e_shentsize 对应”Size of section headers”，表示section header table中每个元素的大小，这里为64个字节；
-    UINT16      elfShNum;               /* Section header table entry count *///e_shnum 对应”Number of section headers”，表示section header table中元素的个数，这里为30个；
-    UINT16      elfShStrIndex;          /* Section header string table index *///e_shstrndx  对应”Section header string table index”，表示描述各section字符名称的string table在section header table中的下标，详见后文对string table的介绍。
+    UINT32      elfVersion;             /* Object file version *///表示文件版本号
+    UINT32      elfEntry;               /* Entry point virtual address *///对应`Entry point address`，程序入口函数地址，通过进程虚拟地址空间地址表达
+    UINT32      elfPhoff;               /* Program header table file offset *///对应`Start of program headers`，表示program header table在文件内的偏移位置
+    UINT32      elfShoff;               /* Section header table file offset *///对应`Start of section headers`，表示section header table在文件内的偏移位置
+    UINT32      elfFlags;               /* Processor-specific flags *///表示与CPU处理器架构相关的信息
+    UINT16      elfHeadSize;            /* ELF header size in bytes *///对应`Size of this header`，表示本ELF header自身的长度
+    UINT16      elfPhEntSize;           /* Program header table entry size *///对应`Size of program headers`，表示program header table中每个元素的大小
+    UINT16      elfPhNum;               /* Program header table entry count *///对应`Number of program headers`，表示program header table中元素个数
+    UINT16      elfShEntSize;           /* Section header table entry size *///对应`Size of section headers`，表示section header table中每个元素的大小
+    UINT16      elfShNum;               /* Section header table entry count *///对应`Number of section headers`，表示section header table中元素的个数
+    UINT16      elfShStrIndex;          /* Section header string table index *///对应`Section header string table index`，表示描述各section字符名称的string table在section header table中的下标
 } LDElf32Ehdr;
 
 
+
 typedef struct {
     UINT8       elfIdent[LD_EI_NIDENT]; /* Magic number and other info */
     UINT16      elfType;                /* Object file type */

zzz/git/push.sh

 git add -A
-git commit -m  'elf 结构体注解
+git commit -m  'ELF结构体注解
     百万汉字注解 + 百篇博客分析 => 挖透鸿蒙内核源码
     https://my.oschina.net/weharmony
 '