我试图了解有关process 0
的更多信息,例如它是否具有内存描述符(非NULL
task_struct->mm
字段)。在我看来,在引导cpu上创建了一个“进程0”,然后由idle_threads_init
为其他cpu创建了一个空闲线程,但是我没有找到第一个进程(我认为那是idle_threads_init
)已创建。
更新
根据tychen引用的process 0
,这是我对live book(对于x86_64而言)的最新理解:
process 0
类型为init_task
的是静态定义的,带有任务的内核堆栈init_task
,内存描述符task_struct
和init_task.stack = init_stack
,其中堆栈区域init_task.mm=NULL
和init_task.active_mm=&init_mm
init_stack
都是静态的定义。init_stack
只有非NULL的事实意味着mm_struct
是一个内核进程。另外,init_mm
。init_mm
以将active_mm
用作内核堆栈。这使process 0
宏有意义(自从机器启动以来,这是第一次),这使init_task.flags=PF_KTHREAD
成为可能。此后,内核将直接在init_task.flags=PF_KTHREAD
的conext中运行。init_stack
-> current
,并且在此功能内,fork()
被分叉。在为process 0
安排的start_kernel
函数中,创建了一个新线程(带有start_kernel
),并对于每个其他逻辑CPU都挂接到CPU的运行队列的arch_call_rest_init
。arch_call_rest_init
(不仅是rest_init
)。通常,线程共享rest_init
,但有不同的process 1&2
,这实际上是Linux的kernel_init
。我猜它不会破坏任何东西,因为空闲线程被锁定到自己的CPU。kernel_init
将加载process 1
可执行文件(通常为CLONE_VM
),并切换到非NULL CLONE_VM
,这使rq->idle
成为合法的用户空间进程。尽管tid 0
不会调整tgid
,但这意味着它仍然是内核进程,与tgid
相同。tid
的末尾,process id
接管,这意味着所有CPU都有一个空闲进程。kernel_init
/ init
之类的/sbin/init
对象/标签全部由mm_struct
使用,而不是process 1
,即[ C0]。我试图了解有关进程0的更多信息,例如它是否具有内存描述符(非NULL task_struct-> mm字段)。在我看来,启动时会创建一个“进程0” ...
从实模式切换到保护模式后。在init / main.c中,有一个函数process 2
,它是进程0的开始。
它将与mm
一起运行process 0