Linux内核中的init_task进程和idle进程

当Power on PC时，BIOS的代码开始执行，然后是Linux初始化的代码，这其中大约很长一段时间Linux都没有进程这一概念，但是这不影响CPU执行它的二进制代码。如果不是多任务以及进程调度的需要，Linux内核可以一直这样走下去。
但是因为多任务的需求，Linux必须能支持任务这一特性，任务即进程，或者更简单地说由task_struct对象实例所代表的一段代码的集合，用以完成特定的任务。所以Linux内核初始化过程中必须为进程以及进程调度做准备。

init_task进程在Linux中属于一个比较特殊的进程，它是内核开发者人为制造出来的，而不是其他进程通过do_fork来完成。init_task对象的初始化在内核代码中由下面代码来完成：

<arch/x86/kernel/init_task.c>

1. struct task_struct init_task = INIT_TASK(init_task);

如果仔细考察INIT_TASK宏的细节，会发现很多有趣的东西，比如inti_task所对应的内核栈，在INIT_TASK宏中由下列代码指定：
.stack        = &init_thread_info
可以猜想init_task进程的内核栈一定是通过静态方式分配的，事实上也的确如此：

< arch/x86/kernel/init_task.c>

1. union thread_union init_thread_union __init_task_data =
   
2.     { INIT_THREAD_INFO(init_task) };

init_thread_info定义中的__init_task_data表明该内核栈所在的区域位于内核映像的init data区，我们可以通过编译完内核后所产生的System.map来看到该变量及其对应的逻辑地址：

root@build-server:/boot# cat System.map-3.1.6 | grep init_thread_union
ffffffff81a00000 D init_thread_union

这意味着init_task.stack = 0x ffffffff81a00000.

Linux在无进程概念的情况下将一直从初始化部分的代码执行到start_kernel，然后再到其最后一个函数调用rest_init。

从rest_init开始，Linux开始产生进程，因为init_task是静态制造出来的，pid=0，它试图将从最早的汇编代码一直到start_kernel的执行都纳入到init_task进程上下文中。在rest_init函数中，内核将通过下面的代码产生第一个真正的进程(pid=1):

<init/main.c>

1. static noinline void __init_refok rest_init(void)
   
2. {
   
3.     ...
   
4.     kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);
   
5.     ...
   
6.     cpu_idle();
   
7. }

kernel_init 函数最有意思的地方在于 它会通过调用kernel_execve来执行根文件系统下的/sbin/init文件(所以此前系统根文件系统必须已经就绪)，kernel_execve对用户空间程序/sbin/init的调用发起自int $0x80，这是个从内核空间发起的系统调用，与call_usermodehelper函数本质上是完全一样的。

而此时init_task的任务基本上已经完全结束了，它将沦落为一个idle task，事实上在更早前的sched_init（）函数中，通过init_idle(current, smp_processor_id())函数的调用就已经把init_task初始化成了一个idle task，init_idle函数的第一个参数current就是&init_task，在init_idle中将会把init_task加入到cpu的运行队列中，这样当运行队列中没有别的就绪进程时，init_task（也就是idle task)将会被调用，它的核心是一个while(1)循环，在循环中它将会调用schedule函数以便在运行队列中有新进程加入时切换到该新进程上。