50_信号消费篇

本篇关键词：、、、

下载 >> 离线文档.鸿蒙内核源码分析(百篇博客分析.挖透鸿蒙内核).pdf

通讯机制相关篇为:

• v41.04 鸿蒙内核源码分析(通讯总览) | 内核跟人一样都喜欢八卦
• v42.08 鸿蒙内核源码分析(自旋锁) | 死等丈夫归来的贞洁烈女
• v43.05 鸿蒙内核源码分析(互斥锁) | 有你没她 相安无事
• v44.02 鸿蒙内核源码分析(快锁使用) | 用户态负责快锁逻辑
• v45.02 鸿蒙内核源码分析(快锁实现) | 内核态负责快锁调度
• v46.01 鸿蒙内核源码分析(读写锁) | 内核如何实现多读单写
• v47.05 鸿蒙内核源码分析(信号量) | 谁在解决任务间的同步
• v48.07 鸿蒙内核源码分析(事件机制) | 多对多任务如何同步
• v49.05 鸿蒙内核源码分析(信号生产) | 年过半百 活力十足
• v50.03 鸿蒙内核源码分析(信号消费) | 谁让CPU连续四次换栈运行
• v51.03 鸿蒙内核源码分析(消息队列) | 进程间如何异步传递大数据
• v52.02 鸿蒙内核源码分析(消息封装) | 剖析LiteIpc(上)进程通讯内容
• v53.01 鸿蒙内核源码分析(消息映射) | 剖析LiteIpc(下)进程通讯机制
• v54.01 鸿蒙内核源码分析(共享内存) | 进程间最快通讯方式

信号消费

本篇为信号消费篇，读之前建议先阅读信号生产篇，信号部分姊妹篇如下:

• v49.xx (信号生产篇) | 年过半百，依然活力十足
• v50.xx (信号消费篇) | 谁让CPU连续四次换栈运行

本篇有相当的难度，涉及用户栈和内核栈的两轮切换，CPU四次换栈，寄存器改值，将围绕下图来说明。

解读

• 为本篇理解方便，把图做简化标签说明:
  • user:用户空间
  • kernel:内核空间
  • source(...):源函数
  • sighandle(...):信号处理函数，
  • syscall(...):系统调用，参数为系统调用号，如sigreturn，N(表任意)
  • user.source():表示在用户空间运行的源函数
• 系列篇已多次说过，用户态的任务有两个运行栈，一个是用户栈，一个是内核栈。栈空间分别来自用户空间和内核空间。两种空间是有严格的地址划分的，通过虚拟地址的大小就能判断出是用户空间还是内核空间。系统调用本质上是软中断，它使CPU执行指令的场地由用户栈变成内核栈。怎么变的并不复杂，就是改变(sp和cpsr寄存器的值)。sp指向哪个栈就代表在哪个栈运行， 当cpu在用户栈运行时是不能访问内核空间的，但内核态任务可以访问整个空间，而且内核态任务没有用户栈。
• 理解了上面的说明，再来说下正常系统调用流程是这样的: user.source() -> kernel。syscall(N) - > user.source() ，想要回到user.source()继续运行，就必须保存用户栈现场各寄存器的值。这些值保存在内核栈中，恢复也是从内核栈恢复。
• 信号消费的过程的上图可简化表示为: user.source() -> kernel。syscall(N) ->user。sighandle() ->kernel。syscall(sigreturn) -> user.source() 在原本要回到user.source()的中间插入了信号处理函数的调用。 这正是本篇要通过代码来说清楚的核心问题。
• 顺着这个思路可以推到以下几点，实际也是这么做的:

  • kernel。syscall(N) 中必须要再次保存user.source()的上下文sig_switch_context，为何已经保存了一次还要再保存一次？

  • 因为第一次是保存在内核栈中，而内核栈这部分数据会因回到用户态user。sighandle()运行而被恢复现场出栈了。保存现场/恢复现场是成双出队的好基友，注意有些文章说会把整个内核栈清空，这是不对的。

  • 第二次保存在任务结构体中，任务来源于任务池，是内核全局变量，常驻内存的。两次保存的都是user.source()运行时现场信息，再回顾下相关的结构体。关键是sig_switch_context

    typedef struct {
        // ...
        sig_cb  sig;//信号控制块，用于异步通信
    } LosTaskCB;
    typedef struct {//信号控制块(描述符)
        sigset_t sigFlag;		//不屏蔽的信号集
        sigset_t sigPendFlag;	//信号阻塞标签集，记录那些信号来过，任务依然阻塞的集合。即:这些信号不能唤醒任务
        sigset_t sigprocmask; /* Signals that are blocked            */	//任务屏蔽了哪些信号
        sq_queue_t sigactionq;	//信号捕捉队列					
        LOS_DL_LIST waitList;	//等待链表，上面挂的是等待信号到来的任务， 请查找 OsTaskWait(&sigcb->waitList， timeout， TRUE)	理解						
        sigset_t sigwaitmask; /* Waiting for pending signals         */	//任务在等待哪些信号的到来
        siginfo_t sigunbinfo; /* Signal info when task unblocked     */	//任务解锁时的信号信息
        sig_switch_context context;	//信号切换上下文， 用于保存切换现场， 比如发生系统调用时的返回，涉及同一个任务的两个栈进行切换			
    } sig_cb;

  • 还必须要改变原有PC/R0/R1寄存器的值。想要执行user。sighandle()，PC寄存器就必须指向它，而R0，R1就是它的参数。

  • 信号处理完成后须回到内核态，怎么再次陷入内核态？ 答案是:__NR_sigreturn，这也是个系统调用。回来后还原sig_switch_context，即还原user.source()被打断时SP/PC等寄存器的值，使其跳回到用户栈从user.source()的被打断处继续执行。

• 有了这三个推论，再理解下面的代码就是吹灰之力了，涉及三个关键函数 OsArmA32SyscallHandle，OsSaveSignalContext，OsRestorSignalContext本篇一一解读，彻底挖透。先看信号上下文结构体sig_switch_context。

sig_switch_context

//任务中断上下文
#define TASK_IRQ_CONTEXT \
        unsigned int R0;     \
        unsigned int R1;     \
        unsigned int R2;     \
        unsigned int R3;     \
        unsigned int R12;    \
        unsigned int USP;    \
        unsigned int ULR;    \
        unsigned int CPSR;   \
        unsigned int PC;

typedef struct {//信号切换上下文
    TASK_IRQ_CONTEXT
    unsigned int R7;	//存放系统调用的ID
    unsigned int count;	//记录是否保存了信号上下文
} sig_switch_context;

• 保存user.source()现场的结构体，USP，ULR代表用户栈指针和返回地址。
• CPSR寄存器用于设置CPU的工作模式，CPU有7种工作模式，具体可前往翻看 v36。xx (工作模式篇)谈论的用户态(usr普通用户)和内核态(sys超级用户)对应的只是其中的两种。二者都共用相同的寄存器。还原它就是告诉CPU内核已切到普通用户模式运行。
• 其他寄存器没有保存的原因是系统调用不会用到它们，所以不需要保存。
• R7是在系统调用发生时用于记录系统调用号，在信号处理过程中，R0将获得信号编号，作为user。sighandle()的第一个参数。
• count记录是否保存了信号上下文

OsArmA32SyscallHandle 系统调用总入口

/* The SYSCALL ID is in R7 on entry。  Parameters follow in R0。。R6 */
/******************************************************************
由汇编调用，见于 los_hw_exc.S    / BLX    OsArmA32SyscallHandle
SYSCALL是产生系统调用时触发的信号，R7寄存器存放具体的系统调用ID，也叫系统调用号
regs:参数就是所有寄存器
注意:本函数在用户态和内核态下都可能被调用到
//MOV     R0， SP @获取SP值，R0将作为OsArmA32SyscallHandle的参数
******************************************************************/
LITE_OS_SEC_TEXT UINT32 *OsArmA32SyscallHandle(UINT32 *regs)
{
    UINT32 ret;
    UINT8 nArgs;
    UINTPTR handle;
    UINT32 cmd = regs[REG_R7];//C7寄存器记录了触发了具体哪个系统调用
    if (cmd >= SYS_CALL_NUM) {//系统调用的总数
        PRINT_ERR("Syscall ID: error %d !!!\n"， cmd);
        return regs;
    }
	//用户进程信号处理函数完成后的系统调用 svc 119 #__NR_sigreturn
    if (cmd == __NR_sigreturn) {
        OsRestorSignalContext(regs);//恢复信号上下文，回到用户栈运行。
        return regs;
    }
    handle = g_syscallHandle[cmd];//拿到系统调用的注册函数，类似 SysRead 
    nArgs = g_syscallNArgs[cmd / NARG_PER_BYTE]; /* 4bit per nargs */
    nArgs = (cmd & 1) ?(nArgs >> NARG_BITS):(nArgs & NARG_MASK);//获取参数个数
    if ((handle == 0) || (nArgs > ARG_NUM_7)) {//系统调用必须有参数且参数不能大于8个
        PRINT_ERR("Unsupport syscall ID: %d nArgs: %d\n"， cmd， nArgs);
        regs[REG_R0] = -ENOSYS;
        return regs;
    }
	//regs[0-6] 记录系统调用的参数，这也是由R7寄存器保存系统调用号的原因
    switch (nArgs) {//参数的个数 
        case ARG_NUM_0:
        case ARG_NUM_1:
            ret = (*(SyscallFun1)handle)(regs[REG_R0]);//执行系统调用，类似 SysUnlink(pathname);
            break;
        case ARG_NUM_2://如何是两个参数的系统调用，这里传三个参数也没有问题，因被调用函数不会去取用R2值
        case ARG_NUM_3:
            ret = (*(SyscallFun3)handle)(regs[REG_R0]， regs[REG_R1]， regs[REG_R2]);//类似 SysExecve(fileName， argv， envp);
            break;
        case ARG_NUM_4:
        case ARG_NUM_5:
            ret = (*(SyscallFun5)handle)(regs[REG_R0]， regs[REG_R1]， regs[REG_R2]， regs[REG_R3]，
                                         regs[REG_R4]);
            break;
        default:	//7个参数的情况
            ret = (*(SyscallFun7)handle)(regs[REG_R0]， regs[REG_R1]， regs[REG_R2]， regs[REG_R3]，
                                         regs[REG_R4]， regs[REG_R5]， regs[REG_R6]);
    }
    regs[REG_R0] = ret;//R0保存系统调用返回值
    OsSaveSignalContext(regs);//如果有信号要处理，将改写pc，r0，r1寄存器，改变返回正常用户态路径，而先去执行信号处理程序。
    /* Return the last value of curent_regs。  This supports context switches on return from the exception。
     * That capability is only used with the SYS_context_switch system call。
     */
    return regs;//返回寄存器的值
}

解读

• 这是系统调用的总入口，所有的系统调用都要跑这里要统一处理。通过系统号(保存在R7)，找到注册函数并回调。完成系统调用过程。
• 关于系统调用可查看 v37。xx (系统调用篇) | 系统调用到底经历了什么 本篇不详细说系统调用过程，只说跟信号相关的部分。
• OsArmA32SyscallHandle总体理解起来是被信号的保存和还原两个函数给包夹了。注意要在运行过程中去理解调用两个函数的过程，对于同一个任务来说，一定是先执行OsSaveSignalContext，第二次进入OsArmA32SyscallHandle后再执行OsRestorSignalContext。
• 看OsSaveSignalContext，由它负责保存user.source() 的上下文，其中改变了sp，r0/r1寄存器值，切到信号处理函数user。sighandle()运行。
• 在函数的开头，碰到系统调用号__NR_sigreturn，直接恢复信号上下文就退出了，因为这是要切回user.source()继续运行的操作。

//用户进程信号处理函数完成后的系统调用 svc 119 #__NR_sigreturn
if (cmd == __NR_sigreturn) {
    OsRestorSignalContext(regs);//恢复信号上下文，回到用户栈运行。
    return regs;
}

OsSaveSignalContext 保存信号上下文

有了上面的铺垫，就不难理解这个函数的作用。

/**********************************************
产生系统调用时，也就是软中断时，保存用户栈寄存器现场信息
改写PC寄存器的值
**********************************************/
void OsSaveSignalContext(unsigned int *sp)
{
    UINTPTR sigHandler;
    UINT32 intSave;
    LosTaskCB *task = NULL;
    LosProcessCB *process = NULL;
    sig_cb *sigcb = NULL;
    unsigned long cpsr;
    OS_RETURN_IF_VOID(sp == NULL);
    cpsr = OS_SYSCALL_GET_CPSR(sp);//获取系统调用时的 CPSR值
    OS_RETURN_IF_VOID(((cpsr & CPSR_MASK_MODE) != CPSR_USER_MODE));//必须工作在CPU的用户模式下，注意CPSR_USER_MODE(cpu层面)和OS_USER_MODE(系统层面)是两码事。
    SCHEDULER_LOCK(intSave);//如有不明白前往 https://my.oschina.net/weharmony 翻看工作模式/信号分发/信号处理篇
    task = OsCurrTaskGet();
    process = OsCurrProcessGet();
    sigcb = &task->sig;//获取任务的信号控制块
	//1。未保存任务上下文任务
	//2。任何的信号标签集不为空或者进程有信号要处理
    if ((sigcb->context.count == 0) && ((sigcb->sigFlag != 0) || (process->sigShare != 0))) {
        sigHandler = OsGetSigHandler();//获取信号处理函数
        if (sigHandler == 0) {//信号没有注册
            sigcb->sigFlag = 0;
            process->sigShare = 0;
            SCHEDULER_UNLOCK(intSave);
            PRINT_ERR("The signal processing function for the current process pid =%d is NULL!\n"， task->processID);
            return;
        }
        /* One pthread do the share signal */ 
        sigcb->sigFlag |= process->sigShare;//扩展任务的信号标签集
        unsigned int signo = (unsigned int)FindFirstSetedBit(sigcb->sigFlag) + 1;
        OsProcessExitCodeSignalSet(process， signo);//设置进程退出信号
        sigcb->context.CPSR = cpsr;		//保存状态寄存器
        sigcb->context.PC = sp[REG_PC]; //获取被打断现场寄存器的值
        sigcb->context.USP = sp[REG_SP];//用户栈顶位置，以便能从内核栈切回用户栈
        sigcb->context.ULR = sp[REG_LR];//用户栈返回地址
        sigcb->context.R0 = sp[REG_R0];	//系统调用的返回值
        sigcb->context.R1 = sp[REG_R1];
        sigcb->context.R2 = sp[REG_R2];
        sigcb->context.R3 = sp[REG_R3]; 
        sigcb->context.R7 = sp[REG_R7];//为何参数不用传R7，是因为系统调用发生时 R7始终保存的是系统调用号。
        sigcb->context.R12 = sp[REG_R12];//详见 https://my.oschina.net/weharmony/blog/4967613
        sp[REG_PC] = sigHandler;//指定信号执行函数，注意此处改变保存任务上下文中PC寄存器的值，恢复上下文时将执行这个函数。
        sp[REG_R0] = signo;		//参数1，信号ID
        sp[REG_R1] = (unsigned int)(UINTPTR)(sigcb->sigunbinfo。si_value。sival_ptr); //参数2
        /* sig No bits 00000100 present sig No 3， but  1<< 3 = 00001000， so signo needs minus 1 */
        sigcb->sigFlag ^= 1ULL << (signo - 1);
        sigcb->context.count++;	//代表已保存
    }
    SCHEDULER_UNLOCK(intSave);
}

解读

• 先是判断执行条件，确实是有信号需要处理，有处理函数。自定义处理函数是由用户进程安装进来的，所有进程旗下的任务都共用，参数就是信号signo，注意可不是系统调用号，有区别的。信号编号长这样。

  #define SIGHUP    1	//终端挂起或者控制进程终止
  #define SIGINT    2	//键盘中断（ctrl + c）
  #define SIGQUIT   3	//键盘的退出键被按下
  #define SIGILL    4	//非法指令
  #define SIGTRAP   5	//跟踪陷阱（trace trap），启动进程，跟踪代码的执行
  #define SIGABRT   6	//由abort(3)发出的退出指令
  #define SIGIOT    SIGABRT //abort发出的信号
  #define SIGBUS    7	//总线错误 
  #define SIGFPE    8	//浮点异常
  #define SIGKILL   9	//常用的命令 kill 9 123 | 不能被忽略、处理和阻塞

  系统调用号长这样，是不是看到一些很熟悉的函数。

  #define __NR_restart_syscall 0
  #define __NR_exit 1
  #define __NR_fork 2
  #define __NR_read 3
  #define __NR_write 4
  #define __NR_open 5
  #define __NR_close 6
  #define __NR_waitpid 7
  #define __NR_creat 8
  #define __NR_link 9
  #define __NR_unlink 10
  #define __NR_execve 11
  #define __NR_chdir 12
  #define __NR_time 13
  #define __NR_mknod 14
  #define __NR_chmod 15
  #define __NR_lchown 16
  #define __NR_break 17

• 最后是最最最关键的代码，改变pc寄存器的值，此值一变，在_osExceptSwiHdl中恢复上下文后，cpu跳到用户空间的代码段 user。sighandle(R0，R1) 开始执行，即执行信号处理函数。

  sp[REG_PC] = sigHandler;//指定信号执行函数，注意此处改变保存任务上下文中PC寄存器的值，恢复上下文时将执行这个函数。
  sp[REG_R0] = signo;		//参数1，信号ID
  sp[REG_R1] = (unsigned int)(UINTPTR)(sigcb->sigunbinfo。si_value。sival_ptr); //参数2

OsRestorSignalContext 恢复信号上下文

/****************************************************
恢复信号上下文，由系统调用之__NR_sigreturn产生，这是一个内部产生的系统调用。
为什么要恢复呢？
因为系统调用的执行由任务内核态完成，使用的栈也是内核栈，CPU相关寄存器记录的都是内核栈的内容，
而系统调用完成后，需返回任务的用户栈执行，这时需将CPU各寄存器回到用户态现场
所以函数的功能就变成了还原寄存器的值
****************************************************/
void OsRestorSignalContext(unsigned int *sp)
{
    LosTaskCB *task = NULL; /* Do not adjust this statement */
    LosProcessCB *process = NULL;
    sig_cb *sigcb = NULL;
    UINT32 intSave;
    SCHEDULER_LOCK(intSave);
    task = OsCurrTaskGet();
    sigcb = &task->sig;//获取当前任务信号控制块
    if (sigcb->context.count != 1) {//必须之前保存过，才能被恢复
        SCHEDULER_UNLOCK(intSave);
        PRINT_ERR("sig error count : %d\n"， sigcb->context.count);
        return;
    }
    process = OsCurrProcessGet();//获取当前进程
    sp[REG_PC] = sigcb->context.PC;//指令寄存器
    OS_SYSCALL_SET_CPSR(sp， sigcb->context.CPSR);//重置程序状态寄存器
    sp[REG_SP] = sigcb->context.USP;//用户栈堆栈指针， USP指的是 用户态的堆栈，即将回到用户栈继续运行
    sp[REG_LR] = sigcb->context.ULR;//返回用户栈代码执行位置
    sp[REG_R0] = sigcb->context.R0;
    sp[REG_R1] = sigcb->context.R1;
    sp[REG_R2] = sigcb->context.R2;
    sp[REG_R3] = sigcb->context.R3;
    sp[REG_R7] = sigcb->context.R7;
    sp[REG_R12] = sigcb->context.R12;
    sigcb->context.count--;	//信号上下文的数量回到减少
    process->sigShare = 0;	//回到用户态，信号共享清0
    OsProcessExitCodeSignalClear(process);//清空进程退出码
    SCHEDULER_UNLOCK(intSave);
}

解读

• 在信号处理函数完成之后，内核会触发一个__NR_sigreturn的系统调用，又陷入内核态，回到了OsArmA32SyscallHandle。

• 恢复的过程很简单，把之前保存的信号上下文恢复到内核栈sp开始位置，数据在栈中的保存顺序可查看 用栈方式篇 ，最重要的看这几句。

  sp[REG_PC] = sigcb->context.PC;//指令寄存器
  sp[REG_SP] = sigcb->context.USP;//用户栈堆栈指针， USP指的是 用户态的堆栈，即将回到用户栈继续运行
  sp[REG_LR] = sigcb->context.ULR;//返回用户栈代码执行位置

  注意这里还不是真正的切换上下文，只是改变内核栈中现有的数据。这些数据将还原给寄存器。USP和ULR指向的是用户栈的位置。一旦PC，USP，ULR从栈中弹出赋给寄存器。才真正完成了内核栈到用户栈的切换。回到了user.source()继续运行。

• 真正的切换汇编代码如下，都已添加注释，在保存和恢复上下文中夹着OsArmA32SyscallHandle

  @ Description: Software interrupt exception handler
  _osExceptSwiHdl: @软中断异常处理，注意此时已在内核栈运行
  @保存任务上下文(TaskContext) 开始... 一定要对照TaskContext来理解
  SUB     SP， SP， #(4 * 16)	@先申请16个栈空间单元用于处理本次软中断
  STMIA   SP， {R0-R12}		@Taskcontext.R[GEN_REGS_NUM] STMIA从左到右执行，先放R0 。。 R12
  MRS     R3， SPSR			@读取本模式下的SPSR值
  MOV     R4， LR				@保存回跳寄存器LR
  
  AND     R1， R3， #CPSR_MASK_MODE                          @ Interrupted mode 获取中断模式
  CMP     R1， #CPSR_USER_MODE                              @ User mode	是否为用户模式
  BNE     OsKernelSVCHandler                               @ Branch if not user mode 非用户模式下跳转
  @ 当为用户模式时，获取SP和LR寄出去值
  @ we enter from user mode， we need get the values of  USER mode r13(sp) and r14(lr)。
  @ stmia with ^ will return the user mode registers (provided that r15 is not in the register list)。
  MOV     R0， SP											 @获取SP值，R0将作为OsArmA32SyscallHandle的参数
  STMFD   SP!， {R3}                                        @ Save the CPSR 入栈保存CPSR值 => Taskcontext.regPSR
  ADD     R3， SP， #(4 * 17)                                @ Offset to pc/cpsr storage 跳到PC/CPSR存储位置
  STMFD   R3!， {R4}                                        @ Save the CPSR and r15(pc) 保存LR寄存器 => Taskcontext.PC
  STMFD   R3， {R13， R14}^                                  @ Save user mode r13(sp) and r14(lr) 从右向左 保存 => Taskcontext.LR和SP
  SUB     SP， SP， #4										 @ => Taskcontext.resved
  PUSH_FPU_REGS R1	@保存中断模式(用户模式)											
  @保存任务上下文(TaskContext) 结束
  MOV     FP， #0                                           @ Init frame pointer
  CPSIE   I	@开中断，表明在系统调用期间可响应中断
  BLX     OsArmA32SyscallHandle	/*交给C语言处理系统调用，参数为R0，指向TaskContext的开始位置*/
  CPSID   I	@执行后续指令前必须先关中断
  @恢复任务上下文(TaskContext) 开始
  POP_FPU_REGS R1											 @弹出FPU值给R1
  ADD     SP， SP，#4										 @ 定位到保存旧SPSR值的位置
  LDMFD   SP!， {R3}                                        @ Fetch the return SPSR 弹出旧SPSR值
  MSR     SPSR_cxsf， R3                                    @ Set the return mode SPSR 恢复该模式下的SPSR值
  
  @ we are leaving to user mode， we need to restore the values of USER mode r13(sp) and r14(lr)。
  @ ldmia with ^ will return the user mode registers (provided that r15 is not in the register list)
  
  LDMFD   SP!， {R0-R12}									 @恢复R0-R12寄存器
  LDMFD   SP， {R13， R14}^                                  @ Restore user mode R13/R14 恢复用户模式的R13/R14寄存器
  ADD     SP， SP， #(2 * 4)								 @定位到保存旧PC值的位置
  LDMFD   SP!， {PC}^                                       @ Return to user 切回用户模式运行
  @恢复任务上下文(TaskContext) 结束
  

百文说内核 | 抓住主脉络

• 百文相当于摸出内核的肌肉和器官系统，让人开始丰满有立体感，因是直接从注释源码起步，在加注释过程中，每每有心得处就整理,慢慢形成了以下文章。内容立足源码，常以生活场景打比方尽可能多的将内核知识点置入某种场景，具有画面感，容易理解记忆。说别人能听得懂的话很重要! 百篇博客绝不是百度教条式的在说一堆诘屈聱牙的概念，那没什么意思。更希望让内核变得栩栩如生，倍感亲切。
• 与代码需不断debug一样，文章内容会存在不少错漏之处，请多包涵，但会反复修正，持续更新，v**.xx 代表文章序号和修改的次数，精雕细琢，言简意赅，力求打造精品内容。
• 百文在 < 鸿蒙研究站 | 开源中国 | 博客园 | 51cto | csdn | 知乎 | 掘金 > 站点发布，百篇博客系列目录如下。
• 

按功能模块:

基础知识	进程管理	任务管理	内存管理
双向链表 内核概念 源码结构 地址空间 计时单位 优雅的宏 钩子框架 位图管理 POSIX main函数	调度故事 进程控制块 进程空间 线性区 红黑树 进程管理 Fork进程 进程回收 Shell编辑 Shell解析	任务控制块 并发并行 就绪队列 调度机制 任务管理 用栈方式 软件定时器 控制台 远程登录 协议栈	内存规则 物理内存 内存概念 虚实映射 页表管理 静态分配 TLFS算法 内存池管理 原子操作 圆整对齐
通讯机制	文件系统	硬件架构	内核汇编
通讯总览 自旋锁 互斥锁 快锁使用 快锁实现 读写锁 信号量 事件机制 信号生产 信号消费 消息队列 消息封装 消息映射 共享内存	文件概念 文件故事 索引节点 VFS 文件句柄 根文件系统 挂载机制 管道文件 文件映射 写时拷贝	芯片模式 ARM架构 指令集 协处理器 工作模式 寄存器 多核管理 中断概念 中断管理	编码方式 汇编基础 汇编传参 链接脚本 内核启动 进程切换 任务切换 中断切换 异常接管 缺页中断
编译运行	调测工具
编译过程 编译构建 GN语法 忍者无敌 ELF格式 ELF解析 静态链接 重定位 动态链接 进程映像 应用启动 系统调用 VDSO	模块监控 日志跟踪 系统安全 测试用例

百万注源码 | 处处扣细节

• 百万汉字注解内核目的是要看清楚其毛细血管，细胞结构，等于在拿放大镜看内核。内核并不神秘，带着问题去源码中找答案是很容易上瘾的，你会发现很多文章对一些问题的解读是错误的，或者说不深刻难以自圆其说，你会慢慢形成自己新的解读，而新的解读又会碰到新的问题，如此层层递进，滚滚向前，拿着放大镜根本不愿意放手。

• < gitee | github | coding | gitcode > 四大码仓推送 | 同步官方源码。

  

关注不迷路 | 代码即人生

期间不断得到小伙伴的支持，有学生，有职场新人，也有老江湖，在此一并感谢，大家的支持是前进的动力。尤其每次收到学生的赞助很感慨，后生可敬。 >> 查看捐助名单

据说喜欢 点赞 + 分享 的,后来都成了大神。:)