Linux内核是否需要文件系统才能运行?


19

我的看法是肯定的,但确实如此,因为所有对外界的有用暴露(非特权处理器模式)首先都需要一个在外部运行的进程。这将需要一个文件系统,甚至是一个临时的RAM中文件系统。

另一位工程师不同意我的观点,但我似乎无法在所有(我不知道)的情况下证明这一点。

这个问题的答案是否取决于“运行”的定义?


4
我认为正在运行的内核不需要“请求”useful exposure to the outside world
jsotola

19
让我们想起旧的停止的Linux防火墙(大约在2002年)
杰夫·谢勒

1
如果将新代码添加到内核,则可以执行任何操作。如果不能,它将初始化到尝试运行的位置init(第一个用户空间进程),然后失败。
user253751

1
定义“运行” ...
托尔比约恩Ravn的安德森

Answers:


27

这是一个很奇怪的问题,因为您不会像运行程序那样运行内核。内核是在其上运行程序的平台。当然,有设置和关闭代码,但是无法单独运行内核。必须始终有一个主要的“初始化”过程。如果内核不存在,内核将惊慌。如果init尝试退出,内核也会出现恐慌。

如今,初始化过程类似于systemd。如果没有另外指定,内核将尝试从以/sbin/init。开头的位置列表中运行程序。在紧急情况下,您可以通过http://man7.org/linux/man-pages/man7/bootparam.7.html参阅init参数init=/bin/bash。但是请注意如何始终在文件系统上指定要运行的文件。

因此,如果内核启动了没有文件系统的文件,它将陷入恐慌,因为没有文件系统,就无法加载init。

由于鸡和蛋的情况,内核必须加载驱动程序才能访问其文件系统,因此可能会引起一些混乱。为了解决这个问题,首先从磁盘上的映像加载了初始虚拟磁盘,该映像包含重要的驱动程序和安装脚本。这些在加载文件系统之前执行。但是,毫无疑问,最初的虚拟磁盘本身就是一个文件系统。使用初始ramdisk会/init被调用(存储在初始ramdisk中)。在许多发行版中,最终的要求是/sbin/init。同样,没有文件系统,这是不可能的。


内核是否没有放弃尝试初始化硬件并加载已知文件系统(不是通过init参数传递给initrd的initrd),而是掉入非常有限的shell(没有init = / bin / bash)的情况?而且,由于您启动了/ bin / bash,即使内核是使用其他可能会消除此问题的.config选项构建的,内核也将始终具有可用的最小文件系统吗?
Peter L.

1
@PeterL。限制外壳是initrd / initramfs / IIRC引导的任何外壳。
穆鲁

3
请注意,您可以将initramfs(CPIO归档文件提取到ramfs或tmpfs文件系统中)构建内核中。是否将其视为内核“需要文件系统”取决于您,因为这意味着您可以引导内核,只有内核可以启动,并且具有功能正常(如果有一点限制)的系统。还要注意,即使您将内核修补为不再需要初始化,它仍将创建永远不会公开的内部虚拟文件系统。
森林

@forest系统不一定是“受限的”-您可以将systemd和gnome打包到initrd中(以及实际上有用的东西;-)。initramfs中的一个限制是(仍然是?),这是不支持扩展属性-我的工作围绕它在Android通过在initrd的cpio归档,然后将其安装在距离一个循环设备的ext4的图像init.$DEV.rc脚本。
比利叔叔

1
@IsmaelMiguel,不,一个initramfs本身就是一个cpio存档。Squashfs是嵌入式文件系统的不错选择,并且可以制作一个使用它的initrd(相对于initramfs)(这些术语通常可以互换使用,但它们不是完全一样的东西),但它不是Linux解压缩成的格式。 initramfs。(实际上,无需使用squashfs图像即可完全使用它;它已正确索引了)。
查尔斯·达菲

16

答案将取决于您是不是直接使用文件系统,还是要解释的问题与实际陈述的含义有所不同。对于问题的解释方式略有不同的答案是:

  • 在没有任何块设备的情况下运行Linux 是完全可行的,并且对于某些特殊的用例很有用。
  • 在没有任何文件系统的情况下运行Linux 将需要重写内核代码的某些部分,这不太可能是有用的工作。
  • 在不使用任何文件描述符的情况下运行Linux 将需要大量的精力。我很确定这是不值得的。

您必须重写部分内核代码才能创建没有文件系统的工作系统,原因如下:

  • 每个线程都有一个根目录和一个当前工作目录,该目录必须指向某个文件系统。
  • 程序由execve需要文件系统中的可执行文件的系统调用启动。
  • 内核在引导过程中创建基于内存的文件系统。

程序启动后,可以使用execve它取消启动程序的可执行文件的映射,但是为了这样做而不会立即崩溃,它首先必须创建一个不由文件支持的可执行文件内存映射,并且必须在跳转到该文件并取消映射可执行文件之前使用一些有用的代码对其进行初始化。

因此,正在运行的用户模式程序可以以没有文件支持的内存映射的状态存在,并且可以关闭文件支持的所有文件描述符。它不能停止拥有根目录和当前工作目录,但是可以避免使用这些目录。

因此,尽管在这种状态下您可以实现内核代码以将文件系统从程序中剥离下来并使其继续运行,但这听起来并不有用。在没有使用文件系统的中间状态的情况下进入最终状态将变得更加艰巨,没有任何好处。

针对某些特殊用例的有用设置

避免使用块设备可能会很有用。在引导过程中,内核会创建一个内存文件系统,并且它还可以cpio在执行之前使用存档中的内容填充该文件系统init。这样,您可以完全从基于内存的文件系统运行系统,而无需任何块设备来支持它。

这对于不希望保留任何状态并且希望系统在重新启动时从干净的状态启动的系统很有用。

当然,在赋予内核控制权之前,内核和cpio存档必须以某种方式存在于内存中。他们如何到达那里是引导加载程序的工作。即使最终运行的系统不使用块设备,引导加载程序也可能已经从块设备中加载了那些。但是引导加载程序也有可能无需使用块设备即可获取内核和cpio存档,例如通过网络引导。


1
问题是,具有任何内置配置(无需重写任何内容)的Linux内核是否可以在没有任何文件系统的情况下“运行”。它不必执行任何有用的操作或保留状态。从所有答案中,我了解到至少在关机之前,内核内部已提供并假定某种文件系统。甚至“ /”也是一个文件系统。因此,我认为简化答案是“是”。
Peter L.

2
@PeterL。是的,如果您不重写任何内容,Linux将需要文件系统。当人们谈论不带文件系统的Linux的实际用途时,通常是指由块设备支持的Linux,而您可以在不具有由块设备支持的文件系统的情况下运行Linux。您仍然会有某种文件系统。
卡巴斯德

3

在Linux中,几乎每个设备都是一个文件,因此您必须具有一个文件系统才能运行它。


8
但是,当然,设备驱动程序存在于内核中,而与设备文件是否指向它们无关。
菲利普·库灵

6
并非每个设备都是文件。网络接口(eth0wlan0等等)都没有,例如。
Ruslan

1
这是一个普遍的误解。尽管从理论上讲,所有内容在UNIX和类似UNIX的系统中都是文件,但仅对于高度专业的系统(如Plan 9)完全正确(尽管比Windows更真实)。对于Linux,很多东西不是文件。这是越来越多的真正的许多司机都开始使用网络链路,而不是字符设备的ioctl(这文件)。
森林

@forest Plan 9不是一个“高度专业化”的系统,它应该是像Unix或Windows这样的通用系统(为什么它不能取代Unix并仍然是研究系统,这是完全不同的故事)。无论如何,就像Linux一样,plan9也在其硬件上公开了虚拟化的接口(并且没有任何ioctl -我看不到如何在所有这些方面使用netlink vs ioctls进行分解),即使它努力使一致性更高(例如网络接口可通过文件系统访问)。随着名称空间的引入,Linux已经比传统的unix更像plan9。
比利叔叔

1
非常好的论点:要么有devfs(每个定义一个文件系统),要么没有devfs,在这种情况下,您需要一个文件系统来托管设备节点……
pmf

-1

内核是一个程序,就像其他程序一样。默认情况下,Linux内核尝试访问文件系统,但是可以通过修改内核(实际上只是添加“ arch_call_rest_init()”函数)来消除这种行为。为了执行“有用的工作”,我们希望开发人员可以在自定义驱动程序中包括perhapos的内核线程(kthread),以执行一些所需的初始化和应用程序类型的工作负载。Linux内核已经包含许多kthread,但主要用于执行内核或驱动程序附带的工作。内核上下文中可用的API与Linux用户空间中可用的API完全不同。在无文件系统的情况下,很大一部分系统调用功能将变得无用。

是的,Linux默认要求访问文件系统。不,可以肯定可以使用经过修改的内核来执行有用的工作,而无需任何文件系统。不带文件系统的Linux的实际使用受到IMO的限制,但不是零。FWIW,在过去,许多实时内核被内置在与RT应用程序相同的名称空间和二进制文件中。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.