完成量是基于等待队列设计的，所以显然不能在中断上下文使用完成量。
struct completion {
unsigned int done;
wait_queue_head_t wait;
};我们来看一个使用完成量的经典例子：
struct kthread_create_info
{
/* Information passed to kthread() from kthreadd. */
int (*threadfn)(void *data);
void *data;
int node; /* Result passed back to kthread_create() from kthreadd. */
struct task_struct *result;
struct completion done; struct list_head list;
};
在创建内核线程的例子中，我们使用了一个kthread_create_info结构来封装了一个完成量：
struct task_struct *kthread_create_on_node(int (*threadfn)(void *data),
void *data, int node,
const char namefmt[],
...)
{
struct kthread_create_info create; create.threadfn = threadfn;---------------要创建的线程的主函数
create.data = data;
create.node = node;
init_completion(&create.done);------------动态初始化完成量 spin_lock(&kthread_create_lock);
list_add_tail(&create.list, &kthread_create_list);-------------加入链表，相当于把请求挂在一个双向循环链表中
spin_unlock(&kthread_create_lock); wake_up_process(kthreadd_task);-----------唤醒处理完成量的内核线程，来处理我们发送的请求
wait_for_completion(&create.done);--------等待完成，这个在等待完成量的期间，会导致本进程睡眠
。。。。。。。
如上代码是提交请求的一侧，那么，处理请求的一侧是怎么完成该任务，并通知到请求方呢？
int kthreadd(void *unused)
{
struct task_struct *tsk = current; /* Setup a clean context for our children to inherit. */
set_task_comm(tsk, "kthreadd");
ignore_signals(tsk);
set_cpus_allowed_ptr(tsk, cpu_all_mask);
set_mems_allowed(node_states[N_MEMORY]); current->flags |= PF_NOFREEZE; for (;;) {
set_current_state(TASK_INTERRUPTIBLE);
if (list_empty(&kthread_create_list))
schedule();
__set_current_state(TASK_RUNNING); spin_lock(&kthread_create_lock);
while (!list_empty(&kthread_create_list)) {
struct kthread_create_info *create; create = list_entry(kthread_create_list.next,
struct kthread_create_info, list);--------------取出请求
list_del_init(&create->list);------------将请求从链表隔离
spin_unlock(&kthread_create_lock);-------解锁，这个锁保证加入请求和解除请求的串行化 create_kthread(create);------------------创建线程 spin_lock(&kthread_create_lock);
}
spin_unlock(&kthread_create_lock);
} return ;
}
简单地看，没看到怎么通知请求方，代码其实是在create_kthread中实现的：
static void create_kthread(struct kthread_create_info *create)
{
int pid; #ifdef CONFIG_NUMA
current->pref_node_fork = create->node;
#endif
/* We want our own signal handler (we take no signals by default). */
pid = kernel_thread(kthread, create, CLONE_FS | CLONE_FILES | SIGCHLD);
if (pid < ) {
create->result = ERR_PTR(pid);
complete(&create->done);-------------------通知请求方，一般就是唤醒了
}
}
以上就是使用完成量的经典例子，两个互不干扰的执行流，一个通过wait_for_completion来等待请求完成，一个通过complete，还有complete_all等来通知请求方，完成交互。
除了动态初始化一个完成量，还有一种静态初始化的方式，
static __initdata DECLARE_COMPLETION(kthreadd_done);
比如我们下面要描述的kthreadd线程，在 rest_init 中调用 的时候：（为啥叫rest_init，个人觉得是，因为包括mm，调度器之类的都已经初始化好了，就剩下这个初始化了，所以叫rest_init
，这个函数还有个特点就是，它最终会调用cpu_startup_entry(CPUHP_ONLINE); 死循环，永不退出，一直处于内核态）
static noinline void __init_refok rest_init(void)
{
int pid; rcu_scheduler_starting();
/*
* We need to spawn init first so that it obtains pid 1, however
* the init task will end up wanting to create kthreads, which, if
* we schedule it before we create kthreadd, will OOPS.
*/
kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);
numa_default_policy();
pid = kernel_thread(kthreadd, NULL, CLONE_FS | CLONE_FILES);------------创建2号进程，也就是kthradd内核线程
rcu_read_lock();
kthreadd_task = find_task_by_pid_ns(pid, &init_pid_ns);
rcu_read_unlock();
complete(&kthreadd_done);------------唤醒被阻塞的进程
在kthreadd 创建之前，
kernel_init-->kernel_init_freeable函数会使用静态初始化的完成量 kthreadd_done 来等待 kthreadd 内核线程创建好。
static noinline void __init kernel_init_freeable(void)
{
/*
* Wait until kthreadd is all set-up.
*/
wait_for_completion(&kthreadd_done);
也就是说，在2号进程，也就是 kthreadd 被创建好之前，1号进程其实是阻塞的。有一个疑问就是，为什么1号进程要等待2号进程呢？因为假设1号进程不等待，那么用户态进程就可能通过
系统调用来获取资源，而如果这些资源是由2号线程或者2号线程的子线程来维护的话，则必然产生oops。所以这个地方的完成量，起的是一个时序的作用。
我们可以看到，内核线程的创建接口，是由 kthreadd 内核线程来完成fork的，
ps -ef |grep -i kthreadd
root 9月15 ? :: [kthreadd]
这个内核线程的pid是2，其他所有的内核线程都是它fork出来的，因为init进程占据了pid 1，所以它的pid是2。
我们假设一下，如果pid 为1的init进程，最终不去执行
if (!run_init_process("/sbin/init") ||
!run_init_process("/etc/init") ||
!run_init_process("/bin/init") ||
!run_init_process("/bin/sh"))那么它这个时候纯粹还是内核线程，它全部工作在内核态，没有用户态进程的os有没有用呢？
我觉得是有的，没有交互罢了，全部在内核态。恩，如果你把一些任务放在内核里面完成，完全可以不要用户态进程嘛。
总结一下：
进程1又称为init进程，是所有用户进程的祖先，注意，是用户进程，不是内核进程，内核进程的祖先是kthreadd，这哥们负责fork所有的内核线程。
由进程0在start_kernel调用rest_init创建
init进程PID为1，当调度程序选择到init进程时，init进程开始执行kernel_init ()函数
init是个普通的用户态进程，它是Unix系统内核初始化与用户态初始化的接合点，它是所有用户进程的祖宗。在运行init以前是内核态初始化，该过程（内核初始化）的最后一个动作就是运行/sbin/init可执行文件。
完成量，既可以完成通信的作用，又可以完成时序控制的作用，既能够动态初始化来完成交互，又可能静态init来完成交互。