【linux】init进程的详解

小鱼儿 2024-03-22 16:17 54阅读 0赞

#### 文章目录 ####

*  概述
 *  init进程完成从内核态向用户态的转变
 *   *  （1）一个进程先后两种状态
     *  （2）init进程在内核态下的工作内容
     *  （3）init进程在用户态下的工作内容
     *  （4）init进程如何从内核态跳跃到用户态 ？还能回来不？
     *   *   *  1、init进程挂载了根文件系统
             *  2、init进程执行init程序完成内核态到用户态的转变
         *  3、init进程构建了用户交互界面
         *  4、init进程打开了控制台
 *  参考

## 概述 ##

注意：`init进程和init程序（linuxrc程序）是有区别的`。init进程一开始就有，它运行于内核态，属于一个内核线程。后来init进程挂载根文件系统，并运行应用程序init程序后，init进程才从内核态转变为用户态。因为转变过程中进程号没有变，还是进程1，所以有人会把init程序（linuxrc程序）当做进程1。但其实init进程除了后来的init程序，还包括内核态下挂载根文件系统等操作。

## init进程完成从内核态向用户态的转变 ##

![在这里插入图片描述][c0f7071808f44e78a7b59df88030bc92.png]  
从上图可以看到Init 的先从内核空间运行，然后切换到用户空间运行

### （1）一个进程先后两种状态 ###

init进程刚开始运行的时候是内核态，它属于一个内核线程，然后运行一个用户态下面的程序后，把自己强行转成用户态（后面的进程需要工作在用户态下）。  
init进程完成了从内核态到用户态的过渡，因此后续的其他进程都可以工作在用户态。

### （2）init进程在内核态下的工作内容 ###

`主要是挂载根文件系统，并试图找到用户态下的那个init程序`。（这句话看出，init进程是早于init程序运行的。）

init进程要把自己转成用户态就必须运行一个用户态的应用程序，要运行这个应用程序就必须得找到这个应用程序，要找到这个应用程序就必须得挂载根文件系统，因为所有的应用程序都在文件系统中。

内核源代码中的所有函数都处于内核态，执行其中任何一个都不能脱离内核态。应用程序必须不属于内核源代码，这样才能保证应用程序处于用户态。这里执行的init程序和内核不在一起，由根文件系统另外提供。

### （3）init进程在用户态下的工作内容 ###

init进程大部分有意义的工作都是在用户态下进行的。  
init进程对操作系统的意义在于，

> 其他所有的用户进程都直接或者间接派生自init进程

。

### （4）init进程如何从内核态跳跃到用户态 ？还能回来不？ ###

`init进程处于内核态时，通过函数kernel_execve来执行一个用户空间编译链接的应用程序就跳跃到用户态了`。

*  跳跃过程中进程号没有改变，一直是进程1。
 *  跳跃过程是单向的，一旦执行init程序转到用户态，整个操作系统就算真正运转起来了，以后只能在用户态下工作，用户态下想要进入内核态只能通过调用API。
 *  跳跃过程是`单向`的，一旦执行init程序转到用户态，整个操作系统就算真正运转起来了，以后只能在用户态下工作，用户态下想要进入内核态只能通过调用API。

##### 1、init进程挂载了根文件系统 #####

（1）prepare\_namespace函数挂载根文件系统。

（2）根文件系统在哪里？根文件系统的文件系统类型是什么？

uboot通过传参来告诉内核这些信息。  
uboot传参中的root=/dev/mmcblk0p2 rw 这一句就是告诉内核根文件系统在哪里。  
uboot传参中的rootfstype=ext3这一句就是告诉内核rootfs的类型。

（3）挂载结果  
![在这里插入图片描述][2cbc132343ff4bc1a247b8b7f37d8c77.png]  
如果内核挂载根文件系统成功，则会打印出：VFS: Mounted root (ext3 filesystem) on device 179:2。（也可能其他数字）  
如果挂载根文件系统失败，则会打印：No filesystem could mount root, tried: yaffs2  
（4）如果内核启动时挂载rootfs失败，则后面无法执行。

内核中设置了启动失败休息5s自动重启的机制，因此这里会自动重启，所以有时候大家会看到反复重启的情况。  
（5）如果挂载rootfs失败，可能的原因有

最常见的错误就是uboot的bootargs设置不对。  
rootfs烧录失败（fastboot烧录不容易出错）。  
rootfs本身制作失败的。

##### 2、init进程执行init程序完成内核态到用户态的转变 #####

![在这里插入图片描述][c13f72c19e9e49b5822490d1487ec84f.png]

（1）一旦挂载rootfs成功，则进入rootfs中寻找应用程序的init程序（在init\_post()函数中），找到后用run\_init\_process去执行。

（2）如果确定init程序是谁？

先从uboot传参cmdline中看有没有指定，如果有指定先执行cmdline中指定的程序。比如init=/linuxrc表示rootfs的根目录下的linuxrc程序就是init程序。  
如果uboot传参cmdline中没有init=xx或者cmdline中指定的这个xx执行失败，还有备用方案。第一备用：/sbin/init，第二备用：/etc/init，第三备用：/bin/init，第四备用：/bin/sh。如果以上都不成功，则没有办法了。  
init=/linuxrc一般指向busybox。

#### 3、init进程构建了用户交互界面 ####

（1）init进程是其他用户进程的老祖宗。

linux系统中一个进程的创建是通过其父进程创建出来的。根据这个理论只要有一个父进程就能生出一堆子孙进程了。  
（2）init启动了login进程（用户登录进程）、命令行进程（提供命令行环境）、shell进程（提供命令解释和执行）。

（3）shell进程启动了其他用户进程。

命令行和shell一旦工作，用户就可以在命令行下通过./xx的方式来执行其他应用程序，每一个应用程序的运行就是一个进程。

#### 4、init进程打开了控制台 ####

![在这里插入图片描述][58f700f06c1a470e944731d5112e5f26.png]  
（1）linux系统中每个进程都有自己的一个文件描述符表，表中存储的是本进程打开的文件。

（2）linux系统中一切皆是文件，因此设备也是以文件的方式来访问的。要访问一个设备，就要打开此设备对应的文件描述符。譬如/dev/fb0这个设备文件就代表LCD显示器设备，/dev/buzzer代表蜂鸣器设备，/dev/console代表控制台设备。

（3）这里打开了/dev/console文件，并且复制了2次文件描述符，一共得到了3个文件描述符。这三个文件描述符分别是0、1、2，就是所谓的标准输入、标准输出、标准错误这3个文件描述符。

（4）进程1打开了这3个文件描述符，因此进程1衍生出来的所有的进程默认都具有这3个文件描述符。

## 参考 ##

[init进程的详解][init]  
[Linux启动过程分析之init进程分析][Linux_init]

[c0f7071808f44e78a7b59df88030bc92.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/d49ca40667ce463595bbead0a609a68c.png
[2cbc132343ff4bc1a247b8b7f37d8c77.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/063835bad01b48509b060382caa1c61e.png
[c13f72c19e9e49b5822490d1487ec84f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/166a0dcd74024b789459fc1ee98a521f.png
[58f700f06c1a470e944731d5112e5f26.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/22/66cb6492ac3645da85a2e2a7a2aae277.png
[init]: https://www.ngui.cc/el/1214400.html?action=onClick
[Linux_init]: https://blog.csdn.net/NUAA1703/article/details/115096547