Does the Linux kernel need a file system to run?2019 Community Moderator ElectionHow pipes work in LinuxDoes Android really use the same kernel as Linux?How to configure Linux to cache file metadata in preference to contents?File system that never breaks (data loss acceptable)When do I need to specify add_efi_memmap as kernel argument in UEFI/EFI boot?What files does the Linux kernel access?Root file system vs partition's file systemWhat parts of the Linux kernel I do not need?Linux/Embedded Linux - Understanding the Kernel and additional BSP specific componentsHow do I run the Linux kernel?Why does the Linux kernel build system use incremental linking or ar T thin archives?
A known event to a history junkie
Is camera lens focus an exact point or a range?
A car is moving at 40 km/h. A fly at 100 km/h, starts from wall towards the car(20 km away)flies to car and back. How many trips can it make?
Is it okay / does it make sense for another player to join a running game of Munchkin?
Simple image editor tool to draw a simple box/rectangle in an existing image
What should I use for Mishna study?
Calculating the number of days between 2 dates in Excel
Have I saved too much for retirement so far?
Perfect riffle shuffles
Female=gender counterpart?
Left multiplication is homeomorphism of topological groups
Is there an wasy way to program in Tikz something like the one in the image?
Freedom of speech and where it applies
node command while defining a coordinate in TikZ
What will be the benefits of Brexit?
Reply ‘no position’ while the job posting is still there (‘HiWi’ position in Germany)
Is there a problem with hiding "forgot password" until it's needed?
Are Warlocks Arcane or Divine?
Simulating a probability of 1 of 2^N with less than N random bits
Why does this part of the Space Shuttle launch pad seem to be floating in air?
Can I rely on these GitHub repository files?
Can a controlled ghast be a leader of a pack of ghouls?
How to interpret the phrase "t’en a fait voir à toi"?
How do I repair my stair bannister?
Does the Linux kernel need a file system to run?
2019 Community Moderator ElectionHow pipes work in LinuxDoes Android really use the same kernel as Linux?How to configure Linux to cache file metadata in preference to contents?File system that never breaks (data loss acceptable)When do I need to specify add_efi_memmap as kernel argument in UEFI/EFI boot?What files does the Linux kernel access?Root file system vs partition's file systemWhat parts of the Linux kernel I do not need?Linux/Embedded Linux - Understanding the Kernel and additional BSP specific componentsHow do I run the Linux kernel?Why does the Linux kernel build system use incremental linking or ar T thin archives?
My opinion is yes, it does, because all useful exposure to the outside world (non-priviledged processor mode) would first require a process running in the outside world. That would require a file system, even a temporary, in-RAM, file system.
Another engineer disagrees with me, but I can't seem to prove this beyond all (unknown to me) cases.
Does the answer to this question depend on the definition of 'running'?
filesystems linux-kernel
asked Mar 21 at 22:43
Peter L.Peter L.
20126
New contributor
Peter L. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
|
show 1 more comment
My opinion is yes, it does, because all useful exposure to the outside world (non-priviledged processor mode) would first require a process running in the outside world. That would require a file system, even a temporary, in-RAM, file system.
Another engineer disagrees with me, but I can't seem to prove this beyond all (unknown to me) cases.
Does the answer to this question depend on the definition of 'running'?
filesystems linux-kernel
asked Mar 21 at 22:43
Peter L.Peter L.
20126
New contributor
Peter L. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
4
i think that a running kernel does not "require"useful exposure to the outside world
– jsotola
Mar 21 at 23:28
19
Brings to mind the old halted Linux firewall (circa 2002)
– Jeff Schaller
Mar 22 at 0:50
1
If you add new code to the kernel, you can do anything. If you can't, it will initialize fine up to the point where it tries to runinit(the first user-space process), and that will fail.
– immibis
Mar 22 at 6:44
1
Define "run"...
– Thorbjørn Ravn Andersen
Mar 22 at 11:49
Read operating system: three easy pieces
– Basile Starynkevitch
Mar 22 at 12:03
|
show 1 more comment
My opinion is yes, it does, because all useful exposure to the outside world (non-priviledged processor mode) would first require a process running in the outside world. That would require a file system, even a temporary, in-RAM, file system.
Another engineer disagrees with me, but I can't seem to prove this beyond all (unknown to me) cases.
Does the answer to this question depend on the definition of 'running'?
filesystems linux-kernel
asked Mar 21 at 22:43
Peter L.Peter L.
20126
New contributor
Peter L. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
My opinion is yes, it does, because all useful exposure to the outside world (non-priviledged processor mode) would first require a process running in the outside world. That would require a file system, even a temporary, in-RAM, file system.
Another engineer disagrees with me, but I can't seem to prove this beyond all (unknown to me) cases.
Does the answer to this question depend on the definition of 'running'?
filesystems linux-kernel
filesystems linux-kernel
asked Mar 21 at 22:43
Peter L.Peter L.
20126
New contributor
Peter L. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked Mar 21 at 22:43
Peter L.Peter L.
20126
New contributor
Peter L. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked Mar 21 at 22:43
Peter L.Peter L.
20126
New contributor
Peter L. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked Mar 21 at 22:43
Peter L.Peter L.
20126
asked Mar 21 at 22:43
Peter L.Peter L.
20126
20126
New contributor
Peter L. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
Peter L. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
Peter L. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
4
i think that a running kernel does not "require"useful exposure to the outside world
– jsotola
Mar 21 at 23:28
19
Brings to mind the old halted Linux firewall (circa 2002)
– Jeff Schaller
Mar 22 at 0:50
1
If you add new code to the kernel, you can do anything. If you can't, it will initialize fine up to the point where it tries to runinit(the first user-space process), and that will fail.
– immibis
Mar 22 at 6:44
1
Define "run"...
– Thorbjørn Ravn Andersen
Mar 22 at 11:49
Read operating system: three easy pieces
– Basile Starynkevitch
Mar 22 at 12:03
|
show 1 more comment
4
i think that a running kernel does not "require"useful exposure to the outside world
– jsotola
Mar 21 at 23:28
19
Brings to mind the old halted Linux firewall (circa 2002)
– Jeff Schaller
Mar 22 at 0:50
1
If you add new code to the kernel, you can do anything. If you can't, it will initialize fine up to the point where it tries to runinit(the first user-space process), and that will fail.
– immibis
Mar 22 at 6:44
1
Define "run"...
– Thorbjørn Ravn Andersen
Mar 22 at 11:49
Read operating system: three easy pieces
– Basile Starynkevitch
Mar 22 at 12:03
4
4
i think that a running kernel does not "require"
useful exposure to the outside world– jsotola
Mar 21 at 23:28
i think that a running kernel does not "require"
useful exposure to the outside world– jsotola
Mar 21 at 23:28
19
19
Brings to mind the old halted Linux firewall (circa 2002)
– Jeff Schaller
Mar 22 at 0:50
Brings to mind the old halted Linux firewall (circa 2002)
– Jeff Schaller
Mar 22 at 0:50
1
1
If you add new code to the kernel, you can do anything. If you can't, it will initialize fine up to the point where it tries to run
init (the first user-space process), and that will fail.– immibis
Mar 22 at 6:44
If you add new code to the kernel, you can do anything. If you can't, it will initialize fine up to the point where it tries to run
init (the first user-space process), and that will fail.– immibis
Mar 22 at 6:44
1
1
Define "run"...
– Thorbjørn Ravn Andersen
Mar 22 at 11:49
Define "run"...
– Thorbjørn Ravn Andersen
Mar 22 at 11:49
Read operating system: three easy pieces
– Basile Starynkevitch
Mar 22 at 12:03
Read operating system: three easy pieces
– Basile Starynkevitch
Mar 22 at 12:03
|
show 1 more comment
3 Answers
3
active
oldest
votes
That's rather an odd question because you don't run the kernel like you run a program. The kernel is a platform to run programs on. Of course there is setup and shutdown code but it's not possible to run the kernel on its own. There must always be a main "init" process. And the kernel will panic if it's not there. If init tries to exit the kernel will also panic.
These days the init process is something like systemd. If not otherwise specified the kernel will try to run a program from a list of locations starting with /sbin/init. See the init Param here http://man7.org/linux/man-pages/man7/bootparam.7.html in an emergency you can boot Linux with init=/bin/bash . But notice how you always specify a file on the file system to run.
So the kernel will panic if it starts up an has no file system because without one there is no way to load init.
Some confusion may arise because of a chicken and egg situation where the kernel must load drivers to access it's file system. To get round this an initial ramdisk is loaded from an image on disk containing vital drivers and setup scripts. These are executed before the file system is loaded. But make no mistake the initial ramdisk is itself a file system.
answered Mar 22 at 0:08
Philip CoulingPhilip Couling
2,2921022
Isn't there a condition where the kernel gives up trying to initialize hardware and load a known file system (not initrd passed into the kernel via init params), then drops into a very limited shell (without init=/bin/bash)? Also, since you bring up /bin/bash, would the kernel always have that minimal file system available, even if it was built with other .config options that could potentially eliminate this?
– Peter L.
Mar 22 at 0:40
1
@PeterL. that limit shell is some shell from the initrd/initramfs/whatever that kernel booted with, IIRC.
– muru
Mar 22 at 2:04
3
Note that you can build the initramfs (a CPIO archive that is extracted into a ramfs or tmpfs filesystem) into the kernel. Whether or not that counts as the kernel "needing a filesystem" is up to you, since it means you can boot the kernel and nothing but the kernel and have a functional (if a bit limited) system. Also note that, even if you patch the kernel to no longer require an init, it will still create internal virtual filesystems that are never exposed.
– forest
Mar 22 at 5:37
@forest The system doesn't have to be "limited" -- you can pack systemd and gnome into your initrd (together with stuff which is actually useful ;-)). One limitation of initramfs was (still is?) that it wasn't supporting extended attributes -- I did work around it on android by including an ext4 image in the initrd cpio archive which was then mounted as a loop device from theinit.$DEV.rcscript.
– Uncle Billy
Mar 22 at 8:48
1
@IsmaelMiguel, nope, an initramfs as such is a cpio archive. Squashfs is a good choice for embedded filesystems, and one could make an initrd (vs an initramfs) that uses it (the terms are often used interchangably but they're not quite the same thing), but it's not the format Linux unpacks into its initramfs. (Indeed, a squashfs image doesn't need to be unpacked before it can be used at all; it's properly indexed).
– Charles Duffy
Mar 22 at 17:23
|
show 2 more comments
The answer is going to depend on whether you literally mean without a file system or if the question is intended to be interpreted a little different from how it is actually stated. The answers for slight variations in how the question is interpreted are:
- Running Linux without any block devices is entirely feasible and useful for some specialized use cases.
- Running Linux without any file system is going to require rewriting some parts of the kernel code and it's unlikely to be a useful effort.
- Running Linux without using any file descriptors is going to require a lot of effort. I'm pretty sure that's not going to be worth the effort.
The reasons you'd have to rewrite parts of the kernel code to make a working system without a file system are:
- Every thread has a root directory and a current working directory which must point to some file system.
- Programs are started by the
execvesystem call which needs an executable from a file system. - The kernel creates a memory based file system during the boot process.
After a program has been started using execve it is possible for it to unmap the executable from which it was started, though in order to do so it without immediately crashing it first have to create an executable memory mapping which isn't backed by a file, and it has to initialize that with some useful code before jumping to it and unmapping the executable.
Thus a running user mode program can exist in a state where it has no memory mappings backed by files and it can close all file descriptors backed by files. It cannot stop having a root directory and current working directory, but it can refrain from those.
So though in this state you could implement kernel code to rip the file system away from under the program and have it keep running, it doesn't sound like it's useful. And getting into that final state without going through an intermediate state of using a file system is going to be even more work for no useful benefit.
A useful setup for some specialized use cases
Avoiding the use of block devices can be useful. During boot the kernel creates a memory file system, and it can also populate that file system with contents from a cpio archive before executing init. That way you can run a system entirely from a memory based file system without any block device to back it.
This can be useful for systems where you don't want to preserve any state and like the system to start from a clean slate upon rebooting.
Of course the kernel and cpio archive have to get somehow exist in memory before the kernel is given control. How they got there is a job for the boot loader. The boot loader could have loaded those from a block device even though the final running system doesn't use block devices. But it's also possible for the boot loader to acquire the kernel and cpio archive without using a block device for example by booting over the network.
answered Mar 22 at 11:28
kasperdkasperd
2,64011129
1
The question is if a Linux kernel in any built configuration (without re-writing anything) can 'run' without any file system. It does not have to do anything useful or preserve a state. From all of the answers, I'm understanding that some sort of file system is provided and assumed within the kernel itself, at least until shutdown. Even '/' is a file system. So, I think to simplify the answer it is 'yes'.
– Peter L.
Mar 22 at 14:58
1
@PeterL. Yes, if you don't rewrite anything Linux will require a file system. When people talk about practical uses for Linux without a file system they would usually be referring to those backed by a block device and you can run Linux without a file system backed by a block device. You'd still have some sort of file system.
– kasperd
2 days ago
add a comment |
In Linux, every device is a file, so you have to have a filesystem to run it.
answered Mar 21 at 22:45
K7AAYK7AAY
772825
8
But of course the device drivers exist inside the kernel irrespective of whether or not a device file points to them.
– Philip Couling
Mar 22 at 0:09
6
Not every device is a file. Network interfaces (eth0,wlan0etc.) aren't, for example.
– Ruslan
Mar 22 at 4:35
1
This is a common misconception. While in theory, everything is a file in UNIX and UNIX-like systems, it is only completely true for highly specialized systems like Plan 9 (though it is far more true than for Windows). For Linux, quite a few things are not files. This is getting more and more true as many drivers have begun to use netlink rather than ioctls on character devices (which are files).
– forest
Mar 22 at 5:34
@forest Plan 9 is not a "highly specialized" system -- it was supposed to be a general purpose system like Unix or windows (why it failed at replacing Unix and remained a research system is a completely different story). Anyways, just as Linux, plan9 is exposing virtualized interfaces to its hardware (and doesn't have any ioctls -- I don't see how using netlink vs ioctls factor in all this), even if it strives to be more consistent (eg. the network interfaces are accessible via the filesystem). With the introduction of namespaces, Linux is already more like plan9 than classic unix.
– Uncle Billy
Mar 22 at 9:11
1
Very nice argument: either there's devfs, which is a filesystem per definition, or there's no devfs, in which case you need a filesystem to host device nodes ...
– pmf
Mar 22 at 14:47
|
show 1 more comment
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Peter L. is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f507837%2fdoes-the-linux-kernel-need-a-file-system-to-run%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
That's rather an odd question because you don't run the kernel like you run a program. The kernel is a platform to run programs on. Of course there is setup and shutdown code but it's not possible to run the kernel on its own. There must always be a main "init" process. And the kernel will panic if it's not there. If init tries to exit the kernel will also panic.
These days the init process is something like systemd. If not otherwise specified the kernel will try to run a program from a list of locations starting with /sbin/init. See the init Param here http://man7.org/linux/man-pages/man7/bootparam.7.html in an emergency you can boot Linux with init=/bin/bash . But notice how you always specify a file on the file system to run.
So the kernel will panic if it starts up an has no file system because without one there is no way to load init.
Some confusion may arise because of a chicken and egg situation where the kernel must load drivers to access it's file system. To get round this an initial ramdisk is loaded from an image on disk containing vital drivers and setup scripts. These are executed before the file system is loaded. But make no mistake the initial ramdisk is itself a file system.
answered Mar 22 at 0:08
Philip CoulingPhilip Couling
2,2921022
Isn't there a condition where the kernel gives up trying to initialize hardware and load a known file system (not initrd passed into the kernel via init params), then drops into a very limited shell (without init=/bin/bash)? Also, since you bring up /bin/bash, would the kernel always have that minimal file system available, even if it was built with other .config options that could potentially eliminate this?
– Peter L.
Mar 22 at 0:40
1
@PeterL. that limit shell is some shell from the initrd/initramfs/whatever that kernel booted with, IIRC.
– muru
Mar 22 at 2:04
3
Note that you can build the initramfs (a CPIO archive that is extracted into a ramfs or tmpfs filesystem) into the kernel. Whether or not that counts as the kernel "needing a filesystem" is up to you, since it means you can boot the kernel and nothing but the kernel and have a functional (if a bit limited) system. Also note that, even if you patch the kernel to no longer require an init, it will still create internal virtual filesystems that are never exposed.
– forest
Mar 22 at 5:37
@forest The system doesn't have to be "limited" -- you can pack systemd and gnome into your initrd (together with stuff which is actually useful ;-)). One limitation of initramfs was (still is?) that it wasn't supporting extended attributes -- I did work around it on android by including an ext4 image in the initrd cpio archive which was then mounted as a loop device from theinit.$DEV.rcscript.
– Uncle Billy
Mar 22 at 8:48
1
@IsmaelMiguel, nope, an initramfs as such is a cpio archive. Squashfs is a good choice for embedded filesystems, and one could make an initrd (vs an initramfs) that uses it (the terms are often used interchangably but they're not quite the same thing), but it's not the format Linux unpacks into its initramfs. (Indeed, a squashfs image doesn't need to be unpacked before it can be used at all; it's properly indexed).
– Charles Duffy
Mar 22 at 17:23
|
show 2 more comments
That's rather an odd question because you don't run the kernel like you run a program. The kernel is a platform to run programs on. Of course there is setup and shutdown code but it's not possible to run the kernel on its own. There must always be a main "init" process. And the kernel will panic if it's not there. If init tries to exit the kernel will also panic.
These days the init process is something like systemd. If not otherwise specified the kernel will try to run a program from a list of locations starting with /sbin/init. See the init Param here http://man7.org/linux/man-pages/man7/bootparam.7.html in an emergency you can boot Linux with init=/bin/bash . But notice how you always specify a file on the file system to run.
So the kernel will panic if it starts up an has no file system because without one there is no way to load init.
Some confusion may arise because of a chicken and egg situation where the kernel must load drivers to access it's file system. To get round this an initial ramdisk is loaded from an image on disk containing vital drivers and setup scripts. These are executed before the file system is loaded. But make no mistake the initial ramdisk is itself a file system.
answered Mar 22 at 0:08
Philip CoulingPhilip Couling
2,2921022
Isn't there a condition where the kernel gives up trying to initialize hardware and load a known file system (not initrd passed into the kernel via init params), then drops into a very limited shell (without init=/bin/bash)? Also, since you bring up /bin/bash, would the kernel always have that minimal file system available, even if it was built with other .config options that could potentially eliminate this?
– Peter L.
Mar 22 at 0:40
1
@PeterL. that limit shell is some shell from the initrd/initramfs/whatever that kernel booted with, IIRC.
– muru
Mar 22 at 2:04
3
Note that you can build the initramfs (a CPIO archive that is extracted into a ramfs or tmpfs filesystem) into the kernel. Whether or not that counts as the kernel "needing a filesystem" is up to you, since it means you can boot the kernel and nothing but the kernel and have a functional (if a bit limited) system. Also note that, even if you patch the kernel to no longer require an init, it will still create internal virtual filesystems that are never exposed.
– forest
Mar 22 at 5:37
@forest The system doesn't have to be "limited" -- you can pack systemd and gnome into your initrd (together with stuff which is actually useful ;-)). One limitation of initramfs was (still is?) that it wasn't supporting extended attributes -- I did work around it on android by including an ext4 image in the initrd cpio archive which was then mounted as a loop device from theinit.$DEV.rcscript.
– Uncle Billy
Mar 22 at 8:48
1
@IsmaelMiguel, nope, an initramfs as such is a cpio archive. Squashfs is a good choice for embedded filesystems, and one could make an initrd (vs an initramfs) that uses it (the terms are often used interchangably but they're not quite the same thing), but it's not the format Linux unpacks into its initramfs. (Indeed, a squashfs image doesn't need to be unpacked before it can be used at all; it's properly indexed).
– Charles Duffy
Mar 22 at 17:23
|
show 2 more comments
That's rather an odd question because you don't run the kernel like you run a program. The kernel is a platform to run programs on. Of course there is setup and shutdown code but it's not possible to run the kernel on its own. There must always be a main "init" process. And the kernel will panic if it's not there. If init tries to exit the kernel will also panic.
These days the init process is something like systemd. If not otherwise specified the kernel will try to run a program from a list of locations starting with /sbin/init. See the init Param here http://man7.org/linux/man-pages/man7/bootparam.7.html in an emergency you can boot Linux with init=/bin/bash . But notice how you always specify a file on the file system to run.
So the kernel will panic if it starts up an has no file system because without one there is no way to load init.
Some confusion may arise because of a chicken and egg situation where the kernel must load drivers to access it's file system. To get round this an initial ramdisk is loaded from an image on disk containing vital drivers and setup scripts. These are executed before the file system is loaded. But make no mistake the initial ramdisk is itself a file system.
answered Mar 22 at 0:08
Philip CoulingPhilip Couling
2,2921022
That's rather an odd question because you don't run the kernel like you run a program. The kernel is a platform to run programs on. Of course there is setup and shutdown code but it's not possible to run the kernel on its own. There must always be a main "init" process. And the kernel will panic if it's not there. If init tries to exit the kernel will also panic.
These days the init process is something like systemd. If not otherwise specified the kernel will try to run a program from a list of locations starting with /sbin/init. See the init Param here http://man7.org/linux/man-pages/man7/bootparam.7.html in an emergency you can boot Linux with init=/bin/bash . But notice how you always specify a file on the file system to run.
So the kernel will panic if it starts up an has no file system because without one there is no way to load init.
Some confusion may arise because of a chicken and egg situation where the kernel must load drivers to access it's file system. To get round this an initial ramdisk is loaded from an image on disk containing vital drivers and setup scripts. These are executed before the file system is loaded. But make no mistake the initial ramdisk is itself a file system.
answered Mar 22 at 0:08
Philip CoulingPhilip Couling
2,2921022
edited Mar 22 at 9:22
answered Mar 22 at 0:08
Philip CoulingPhilip Couling
2,2921022
answered Mar 22 at 0:08
Philip CoulingPhilip Couling
2,2921022
answered Mar 22 at 0:08
Philip CoulingPhilip Couling
2,2921022
2,2921022
Isn't there a condition where the kernel gives up trying to initialize hardware and load a known file system (not initrd passed into the kernel via init params), then drops into a very limited shell (without init=/bin/bash)? Also, since you bring up /bin/bash, would the kernel always have that minimal file system available, even if it was built with other .config options that could potentially eliminate this?
– Peter L.
Mar 22 at 0:40
1
@PeterL. that limit shell is some shell from the initrd/initramfs/whatever that kernel booted with, IIRC.
– muru
Mar 22 at 2:04
3
Note that you can build the initramfs (a CPIO archive that is extracted into a ramfs or tmpfs filesystem) into the kernel. Whether or not that counts as the kernel "needing a filesystem" is up to you, since it means you can boot the kernel and nothing but the kernel and have a functional (if a bit limited) system. Also note that, even if you patch the kernel to no longer require an init, it will still create internal virtual filesystems that are never exposed.
– forest
Mar 22 at 5:37
@forest The system doesn't have to be "limited" -- you can pack systemd and gnome into your initrd (together with stuff which is actually useful ;-)). One limitation of initramfs was (still is?) that it wasn't supporting extended attributes -- I did work around it on android by including an ext4 image in the initrd cpio archive which was then mounted as a loop device from theinit.$DEV.rcscript.
– Uncle Billy
Mar 22 at 8:48
1
@IsmaelMiguel, nope, an initramfs as such is a cpio archive. Squashfs is a good choice for embedded filesystems, and one could make an initrd (vs an initramfs) that uses it (the terms are often used interchangably but they're not quite the same thing), but it's not the format Linux unpacks into its initramfs. (Indeed, a squashfs image doesn't need to be unpacked before it can be used at all; it's properly indexed).
– Charles Duffy
Mar 22 at 17:23
|
show 2 more comments
Isn't there a condition where the kernel gives up trying to initialize hardware and load a known file system (not initrd passed into the kernel via init params), then drops into a very limited shell (without init=/bin/bash)? Also, since you bring up /bin/bash, would the kernel always have that minimal file system available, even if it was built with other .config options that could potentially eliminate this?
– Peter L.
Mar 22 at 0:40
1
@PeterL. that limit shell is some shell from the initrd/initramfs/whatever that kernel booted with, IIRC.
– muru
Mar 22 at 2:04
3
Note that you can build the initramfs (a CPIO archive that is extracted into a ramfs or tmpfs filesystem) into the kernel. Whether or not that counts as the kernel "needing a filesystem" is up to you, since it means you can boot the kernel and nothing but the kernel and have a functional (if a bit limited) system. Also note that, even if you patch the kernel to no longer require an init, it will still create internal virtual filesystems that are never exposed.
– forest
Mar 22 at 5:37
@forest The system doesn't have to be "limited" -- you can pack systemd and gnome into your initrd (together with stuff which is actually useful ;-)). One limitation of initramfs was (still is?) that it wasn't supporting extended attributes -- I did work around it on android by including an ext4 image in the initrd cpio archive which was then mounted as a loop device from theinit.$DEV.rcscript.
– Uncle Billy
Mar 22 at 8:48
1
@IsmaelMiguel, nope, an initramfs as such is a cpio archive. Squashfs is a good choice for embedded filesystems, and one could make an initrd (vs an initramfs) that uses it (the terms are often used interchangably but they're not quite the same thing), but it's not the format Linux unpacks into its initramfs. (Indeed, a squashfs image doesn't need to be unpacked before it can be used at all; it's properly indexed).
– Charles Duffy
Mar 22 at 17:23
Isn't there a condition where the kernel gives up trying to initialize hardware and load a known file system (not initrd passed into the kernel via init params), then drops into a very limited shell (without init=/bin/bash)? Also, since you bring up /bin/bash, would the kernel always have that minimal file system available, even if it was built with other .config options that could potentially eliminate this?
– Peter L.
Mar 22 at 0:40
Isn't there a condition where the kernel gives up trying to initialize hardware and load a known file system (not initrd passed into the kernel via init params), then drops into a very limited shell (without init=/bin/bash)? Also, since you bring up /bin/bash, would the kernel always have that minimal file system available, even if it was built with other .config options that could potentially eliminate this?
– Peter L.
Mar 22 at 0:40
1
1
@PeterL. that limit shell is some shell from the initrd/initramfs/whatever that kernel booted with, IIRC.
– muru
Mar 22 at 2:04
@PeterL. that limit shell is some shell from the initrd/initramfs/whatever that kernel booted with, IIRC.
– muru
Mar 22 at 2:04
3
3
Note that you can build the initramfs (a CPIO archive that is extracted into a ramfs or tmpfs filesystem) into the kernel. Whether or not that counts as the kernel "needing a filesystem" is up to you, since it means you can boot the kernel and nothing but the kernel and have a functional (if a bit limited) system. Also note that, even if you patch the kernel to no longer require an init, it will still create internal virtual filesystems that are never exposed.
– forest
Mar 22 at 5:37
Note that you can build the initramfs (a CPIO archive that is extracted into a ramfs or tmpfs filesystem) into the kernel. Whether or not that counts as the kernel "needing a filesystem" is up to you, since it means you can boot the kernel and nothing but the kernel and have a functional (if a bit limited) system. Also note that, even if you patch the kernel to no longer require an init, it will still create internal virtual filesystems that are never exposed.
– forest
Mar 22 at 5:37
@forest The system doesn't have to be "limited" -- you can pack systemd and gnome into your initrd (together with stuff which is actually useful ;-)). One limitation of initramfs was (still is?) that it wasn't supporting extended attributes -- I did work around it on android by including an ext4 image in the initrd cpio archive which was then mounted as a loop device from the
init.$DEV.rc script.– Uncle Billy
Mar 22 at 8:48
@forest The system doesn't have to be "limited" -- you can pack systemd and gnome into your initrd (together with stuff which is actually useful ;-)). One limitation of initramfs was (still is?) that it wasn't supporting extended attributes -- I did work around it on android by including an ext4 image in the initrd cpio archive which was then mounted as a loop device from the
init.$DEV.rc script.– Uncle Billy
Mar 22 at 8:48
1
1
@IsmaelMiguel, nope, an initramfs as such is a cpio archive. Squashfs is a good choice for embedded filesystems, and one could make an initrd (vs an initramfs) that uses it (the terms are often used interchangably but they're not quite the same thing), but it's not the format Linux unpacks into its initramfs. (Indeed, a squashfs image doesn't need to be unpacked before it can be used at all; it's properly indexed).
– Charles Duffy
Mar 22 at 17:23
@IsmaelMiguel, nope, an initramfs as such is a cpio archive. Squashfs is a good choice for embedded filesystems, and one could make an initrd (vs an initramfs) that uses it (the terms are often used interchangably but they're not quite the same thing), but it's not the format Linux unpacks into its initramfs. (Indeed, a squashfs image doesn't need to be unpacked before it can be used at all; it's properly indexed).
– Charles Duffy
Mar 22 at 17:23
|
show 2 more comments
The answer is going to depend on whether you literally mean without a file system or if the question is intended to be interpreted a little different from how it is actually stated. The answers for slight variations in how the question is interpreted are:
- Running Linux without any block devices is entirely feasible and useful for some specialized use cases.
- Running Linux without any file system is going to require rewriting some parts of the kernel code and it's unlikely to be a useful effort.
- Running Linux without using any file descriptors is going to require a lot of effort. I'm pretty sure that's not going to be worth the effort.
The reasons you'd have to rewrite parts of the kernel code to make a working system without a file system are:
- Every thread has a root directory and a current working directory which must point to some file system.
- Programs are started by the
execvesystem call which needs an executable from a file system. - The kernel creates a memory based file system during the boot process.
After a program has been started using execve it is possible for it to unmap the executable from which it was started, though in order to do so it without immediately crashing it first have to create an executable memory mapping which isn't backed by a file, and it has to initialize that with some useful code before jumping to it and unmapping the executable.
Thus a running user mode program can exist in a state where it has no memory mappings backed by files and it can close all file descriptors backed by files. It cannot stop having a root directory and current working directory, but it can refrain from those.
So though in this state you could implement kernel code to rip the file system away from under the program and have it keep running, it doesn't sound like it's useful. And getting into that final state without going through an intermediate state of using a file system is going to be even more work for no useful benefit.
A useful setup for some specialized use cases
Avoiding the use of block devices can be useful. During boot the kernel creates a memory file system, and it can also populate that file system with contents from a cpio archive before executing init. That way you can run a system entirely from a memory based file system without any block device to back it.
This can be useful for systems where you don't want to preserve any state and like the system to start from a clean slate upon rebooting.
Of course the kernel and cpio archive have to get somehow exist in memory before the kernel is given control. How they got there is a job for the boot loader. The boot loader could have loaded those from a block device even though the final running system doesn't use block devices. But it's also possible for the boot loader to acquire the kernel and cpio archive without using a block device for example by booting over the network.
answered Mar 22 at 11:28
kasperdkasperd
2,64011129
1
The question is if a Linux kernel in any built configuration (without re-writing anything) can 'run' without any file system. It does not have to do anything useful or preserve a state. From all of the answers, I'm understanding that some sort of file system is provided and assumed within the kernel itself, at least until shutdown. Even '/' is a file system. So, I think to simplify the answer it is 'yes'.
– Peter L.
Mar 22 at 14:58
1
@PeterL. Yes, if you don't rewrite anything Linux will require a file system. When people talk about practical uses for Linux without a file system they would usually be referring to those backed by a block device and you can run Linux without a file system backed by a block device. You'd still have some sort of file system.
– kasperd
2 days ago
add a comment |
The answer is going to depend on whether you literally mean without a file system or if the question is intended to be interpreted a little different from how it is actually stated. The answers for slight variations in how the question is interpreted are:
- Running Linux without any block devices is entirely feasible and useful for some specialized use cases.
- Running Linux without any file system is going to require rewriting some parts of the kernel code and it's unlikely to be a useful effort.
- Running Linux without using any file descriptors is going to require a lot of effort. I'm pretty sure that's not going to be worth the effort.
The reasons you'd have to rewrite parts of the kernel code to make a working system without a file system are:
- Every thread has a root directory and a current working directory which must point to some file system.
- Programs are started by the
execvesystem call which needs an executable from a file system. - The kernel creates a memory based file system during the boot process.
After a program has been started using execve it is possible for it to unmap the executable from which it was started, though in order to do so it without immediately crashing it first have to create an executable memory mapping which isn't backed by a file, and it has to initialize that with some useful code before jumping to it and unmapping the executable.
Thus a running user mode program can exist in a state where it has no memory mappings backed by files and it can close all file descriptors backed by files. It cannot stop having a root directory and current working directory, but it can refrain from those.
So though in this state you could implement kernel code to rip the file system away from under the program and have it keep running, it doesn't sound like it's useful. And getting into that final state without going through an intermediate state of using a file system is going to be even more work for no useful benefit.
A useful setup for some specialized use cases
Avoiding the use of block devices can be useful. During boot the kernel creates a memory file system, and it can also populate that file system with contents from a cpio archive before executing init. That way you can run a system entirely from a memory based file system without any block device to back it.
This can be useful for systems where you don't want to preserve any state and like the system to start from a clean slate upon rebooting.
Of course the kernel and cpio archive have to get somehow exist in memory before the kernel is given control. How they got there is a job for the boot loader. The boot loader could have loaded those from a block device even though the final running system doesn't use block devices. But it's also possible for the boot loader to acquire the kernel and cpio archive without using a block device for example by booting over the network.
answered Mar 22 at 11:28
kasperdkasperd
2,64011129
1
The question is if a Linux kernel in any built configuration (without re-writing anything) can 'run' without any file system. It does not have to do anything useful or preserve a state. From all of the answers, I'm understanding that some sort of file system is provided and assumed within the kernel itself, at least until shutdown. Even '/' is a file system. So, I think to simplify the answer it is 'yes'.
– Peter L.
Mar 22 at 14:58
1
@PeterL. Yes, if you don't rewrite anything Linux will require a file system. When people talk about practical uses for Linux without a file system they would usually be referring to those backed by a block device and you can run Linux without a file system backed by a block device. You'd still have some sort of file system.
– kasperd
2 days ago
add a comment |
The answer is going to depend on whether you literally mean without a file system or if the question is intended to be interpreted a little different from how it is actually stated. The answers for slight variations in how the question is interpreted are:
- Running Linux without any block devices is entirely feasible and useful for some specialized use cases.
- Running Linux without any file system is going to require rewriting some parts of the kernel code and it's unlikely to be a useful effort.
- Running Linux without using any file descriptors is going to require a lot of effort. I'm pretty sure that's not going to be worth the effort.
The reasons you'd have to rewrite parts of the kernel code to make a working system without a file system are:
- Every thread has a root directory and a current working directory which must point to some file system.
- Programs are started by the
execvesystem call which needs an executable from a file system. - The kernel creates a memory based file system during the boot process.
After a program has been started using execve it is possible for it to unmap the executable from which it was started, though in order to do so it without immediately crashing it first have to create an executable memory mapping which isn't backed by a file, and it has to initialize that with some useful code before jumping to it and unmapping the executable.
Thus a running user mode program can exist in a state where it has no memory mappings backed by files and it can close all file descriptors backed by files. It cannot stop having a root directory and current working directory, but it can refrain from those.
So though in this state you could implement kernel code to rip the file system away from under the program and have it keep running, it doesn't sound like it's useful. And getting into that final state without going through an intermediate state of using a file system is going to be even more work for no useful benefit.
A useful setup for some specialized use cases
Avoiding the use of block devices can be useful. During boot the kernel creates a memory file system, and it can also populate that file system with contents from a cpio archive before executing init. That way you can run a system entirely from a memory based file system without any block device to back it.
This can be useful for systems where you don't want to preserve any state and like the system to start from a clean slate upon rebooting.
Of course the kernel and cpio archive have to get somehow exist in memory before the kernel is given control. How they got there is a job for the boot loader. The boot loader could have loaded those from a block device even though the final running system doesn't use block devices. But it's also possible for the boot loader to acquire the kernel and cpio archive without using a block device for example by booting over the network.
answered Mar 22 at 11:28
kasperdkasperd
2,64011129
The answer is going to depend on whether you literally mean without a file system or if the question is intended to be interpreted a little different from how it is actually stated. The answers for slight variations in how the question is interpreted are:
- Running Linux without any block devices is entirely feasible and useful for some specialized use cases.
- Running Linux without any file system is going to require rewriting some parts of the kernel code and it's unlikely to be a useful effort.
- Running Linux without using any file descriptors is going to require a lot of effort. I'm pretty sure that's not going to be worth the effort.
The reasons you'd have to rewrite parts of the kernel code to make a working system without a file system are:
- Every thread has a root directory and a current working directory which must point to some file system.
- Programs are started by the
execvesystem call which needs an executable from a file system. - The kernel creates a memory based file system during the boot process.
After a program has been started using execve it is possible for it to unmap the executable from which it was started, though in order to do so it without immediately crashing it first have to create an executable memory mapping which isn't backed by a file, and it has to initialize that with some useful code before jumping to it and unmapping the executable.
Thus a running user mode program can exist in a state where it has no memory mappings backed by files and it can close all file descriptors backed by files. It cannot stop having a root directory and current working directory, but it can refrain from those.
So though in this state you could implement kernel code to rip the file system away from under the program and have it keep running, it doesn't sound like it's useful. And getting into that final state without going through an intermediate state of using a file system is going to be even more work for no useful benefit.
A useful setup for some specialized use cases
Avoiding the use of block devices can be useful. During boot the kernel creates a memory file system, and it can also populate that file system with contents from a cpio archive before executing init. That way you can run a system entirely from a memory based file system without any block device to back it.
This can be useful for systems where you don't want to preserve any state and like the system to start from a clean slate upon rebooting.
Of course the kernel and cpio archive have to get somehow exist in memory before the kernel is given control. How they got there is a job for the boot loader. The boot loader could have loaded those from a block device even though the final running system doesn't use block devices. But it's also possible for the boot loader to acquire the kernel and cpio archive without using a block device for example by booting over the network.
answered Mar 22 at 11:28
kasperdkasperd
2,64011129
answered Mar 22 at 11:28
kasperdkasperd
2,64011129
answered Mar 22 at 11:28
kasperdkasperd
2,64011129
answered Mar 22 at 11:28
kasperdkasperd
2,64011129
2,64011129
1
The question is if a Linux kernel in any built configuration (without re-writing anything) can 'run' without any file system. It does not have to do anything useful or preserve a state. From all of the answers, I'm understanding that some sort of file system is provided and assumed within the kernel itself, at least until shutdown. Even '/' is a file system. So, I think to simplify the answer it is 'yes'.
– Peter L.
Mar 22 at 14:58
1
@PeterL. Yes, if you don't rewrite anything Linux will require a file system. When people talk about practical uses for Linux without a file system they would usually be referring to those backed by a block device and you can run Linux without a file system backed by a block device. You'd still have some sort of file system.
– kasperd
2 days ago
add a comment |
1
The question is if a Linux kernel in any built configuration (without re-writing anything) can 'run' without any file system. It does not have to do anything useful or preserve a state. From all of the answers, I'm understanding that some sort of file system is provided and assumed within the kernel itself, at least until shutdown. Even '/' is a file system. So, I think to simplify the answer it is 'yes'.
– Peter L.
Mar 22 at 14:58
1
@PeterL. Yes, if you don't rewrite anything Linux will require a file system. When people talk about practical uses for Linux without a file system they would usually be referring to those backed by a block device and you can run Linux without a file system backed by a block device. You'd still have some sort of file system.
– kasperd
2 days ago
1
1
The question is if a Linux kernel in any built configuration (without re-writing anything) can 'run' without any file system. It does not have to do anything useful or preserve a state. From all of the answers, I'm understanding that some sort of file system is provided and assumed within the kernel itself, at least until shutdown. Even '/' is a file system. So, I think to simplify the answer it is 'yes'.
– Peter L.
Mar 22 at 14:58
The question is if a Linux kernel in any built configuration (without re-writing anything) can 'run' without any file system. It does not have to do anything useful or preserve a state. From all of the answers, I'm understanding that some sort of file system is provided and assumed within the kernel itself, at least until shutdown. Even '/' is a file system. So, I think to simplify the answer it is 'yes'.
– Peter L.
Mar 22 at 14:58
1
1
@PeterL. Yes, if you don't rewrite anything Linux will require a file system. When people talk about practical uses for Linux without a file system they would usually be referring to those backed by a block device and you can run Linux without a file system backed by a block device. You'd still have some sort of file system.
– kasperd
2 days ago
@PeterL. Yes, if you don't rewrite anything Linux will require a file system. When people talk about practical uses for Linux without a file system they would usually be referring to those backed by a block device and you can run Linux without a file system backed by a block device. You'd still have some sort of file system.
– kasperd
2 days ago
add a comment |
In Linux, every device is a file, so you have to have a filesystem to run it.
answered Mar 21 at 22:45
K7AAYK7AAY
772825
8
But of course the device drivers exist inside the kernel irrespective of whether or not a device file points to them.
– Philip Couling
Mar 22 at 0:09
6
Not every device is a file. Network interfaces (eth0,wlan0etc.) aren't, for example.
– Ruslan
Mar 22 at 4:35
1
This is a common misconception. While in theory, everything is a file in UNIX and UNIX-like systems, it is only completely true for highly specialized systems like Plan 9 (though it is far more true than for Windows). For Linux, quite a few things are not files. This is getting more and more true as many drivers have begun to use netlink rather than ioctls on character devices (which are files).
– forest
Mar 22 at 5:34
@forest Plan 9 is not a "highly specialized" system -- it was supposed to be a general purpose system like Unix or windows (why it failed at replacing Unix and remained a research system is a completely different story). Anyways, just as Linux, plan9 is exposing virtualized interfaces to its hardware (and doesn't have any ioctls -- I don't see how using netlink vs ioctls factor in all this), even if it strives to be more consistent (eg. the network interfaces are accessible via the filesystem). With the introduction of namespaces, Linux is already more like plan9 than classic unix.
– Uncle Billy
Mar 22 at 9:11
1
Very nice argument: either there's devfs, which is a filesystem per definition, or there's no devfs, in which case you need a filesystem to host device nodes ...
– pmf
Mar 22 at 14:47
|
show 1 more comment
In Linux, every device is a file, so you have to have a filesystem to run it.
answered Mar 21 at 22:45
K7AAYK7AAY
772825
8
But of course the device drivers exist inside the kernel irrespective of whether or not a device file points to them.
– Philip Couling
Mar 22 at 0:09
6
Not every device is a file. Network interfaces (eth0,wlan0etc.) aren't, for example.
– Ruslan
Mar 22 at 4:35
1
This is a common misconception. While in theory, everything is a file in UNIX and UNIX-like systems, it is only completely true for highly specialized systems like Plan 9 (though it is far more true than for Windows). For Linux, quite a few things are not files. This is getting more and more true as many drivers have begun to use netlink rather than ioctls on character devices (which are files).
– forest
Mar 22 at 5:34
@forest Plan 9 is not a "highly specialized" system -- it was supposed to be a general purpose system like Unix or windows (why it failed at replacing Unix and remained a research system is a completely different story). Anyways, just as Linux, plan9 is exposing virtualized interfaces to its hardware (and doesn't have any ioctls -- I don't see how using netlink vs ioctls factor in all this), even if it strives to be more consistent (eg. the network interfaces are accessible via the filesystem). With the introduction of namespaces, Linux is already more like plan9 than classic unix.
– Uncle Billy
Mar 22 at 9:11
1
Very nice argument: either there's devfs, which is a filesystem per definition, or there's no devfs, in which case you need a filesystem to host device nodes ...
– pmf
Mar 22 at 14:47
|
show 1 more comment
In Linux, every device is a file, so you have to have a filesystem to run it.
answered Mar 21 at 22:45
K7AAYK7AAY
772825
In Linux, every device is a file, so you have to have a filesystem to run it.
answered Mar 21 at 22:45
K7AAYK7AAY
772825
answered Mar 21 at 22:45
K7AAYK7AAY
772825
answered Mar 21 at 22:45
K7AAYK7AAY
772825
answered Mar 21 at 22:45
K7AAYK7AAY
772825
772825
8
But of course the device drivers exist inside the kernel irrespective of whether or not a device file points to them.
– Philip Couling
Mar 22 at 0:09
6
Not every device is a file. Network interfaces (eth0,wlan0etc.) aren't, for example.
– Ruslan
Mar 22 at 4:35
1
This is a common misconception. While in theory, everything is a file in UNIX and UNIX-like systems, it is only completely true for highly specialized systems like Plan 9 (though it is far more true than for Windows). For Linux, quite a few things are not files. This is getting more and more true as many drivers have begun to use netlink rather than ioctls on character devices (which are files).
– forest
Mar 22 at 5:34
@forest Plan 9 is not a "highly specialized" system -- it was supposed to be a general purpose system like Unix or windows (why it failed at replacing Unix and remained a research system is a completely different story). Anyways, just as Linux, plan9 is exposing virtualized interfaces to its hardware (and doesn't have any ioctls -- I don't see how using netlink vs ioctls factor in all this), even if it strives to be more consistent (eg. the network interfaces are accessible via the filesystem). With the introduction of namespaces, Linux is already more like plan9 than classic unix.
– Uncle Billy
Mar 22 at 9:11
1
Very nice argument: either there's devfs, which is a filesystem per definition, or there's no devfs, in which case you need a filesystem to host device nodes ...
– pmf
Mar 22 at 14:47
|
show 1 more comment
8
But of course the device drivers exist inside the kernel irrespective of whether or not a device file points to them.
– Philip Couling
Mar 22 at 0:09
6
Not every device is a file. Network interfaces (eth0,wlan0etc.) aren't, for example.
– Ruslan
Mar 22 at 4:35
1
This is a common misconception. While in theory, everything is a file in UNIX and UNIX-like systems, it is only completely true for highly specialized systems like Plan 9 (though it is far more true than for Windows). For Linux, quite a few things are not files. This is getting more and more true as many drivers have begun to use netlink rather than ioctls on character devices (which are files).
– forest
Mar 22 at 5:34
@forest Plan 9 is not a "highly specialized" system -- it was supposed to be a general purpose system like Unix or windows (why it failed at replacing Unix and remained a research system is a completely different story). Anyways, just as Linux, plan9 is exposing virtualized interfaces to its hardware (and doesn't have any ioctls -- I don't see how using netlink vs ioctls factor in all this), even if it strives to be more consistent (eg. the network interfaces are accessible via the filesystem). With the introduction of namespaces, Linux is already more like plan9 than classic unix.
– Uncle Billy
Mar 22 at 9:11
1
Very nice argument: either there's devfs, which is a filesystem per definition, or there's no devfs, in which case you need a filesystem to host device nodes ...
– pmf
Mar 22 at 14:47
8
8
But of course the device drivers exist inside the kernel irrespective of whether or not a device file points to them.
– Philip Couling
Mar 22 at 0:09
But of course the device drivers exist inside the kernel irrespective of whether or not a device file points to them.
– Philip Couling
Mar 22 at 0:09
6
6
Not every device is a file. Network interfaces (
eth0, wlan0 etc.) aren't, for example.– Ruslan
Mar 22 at 4:35
Not every device is a file. Network interfaces (
eth0, wlan0 etc.) aren't, for example.– Ruslan
Mar 22 at 4:35
1
1
This is a common misconception. While in theory, everything is a file in UNIX and UNIX-like systems, it is only completely true for highly specialized systems like Plan 9 (though it is far more true than for Windows). For Linux, quite a few things are not files. This is getting more and more true as many drivers have begun to use netlink rather than ioctls on character devices (which are files).
– forest
Mar 22 at 5:34
This is a common misconception. While in theory, everything is a file in UNIX and UNIX-like systems, it is only completely true for highly specialized systems like Plan 9 (though it is far more true than for Windows). For Linux, quite a few things are not files. This is getting more and more true as many drivers have begun to use netlink rather than ioctls on character devices (which are files).
– forest
Mar 22 at 5:34
@forest Plan 9 is not a "highly specialized" system -- it was supposed to be a general purpose system like Unix or windows (why it failed at replacing Unix and remained a research system is a completely different story). Anyways, just as Linux, plan9 is exposing virtualized interfaces to its hardware (and doesn't have any ioctls -- I don't see how using netlink vs ioctls factor in all this), even if it strives to be more consistent (eg. the network interfaces are accessible via the filesystem). With the introduction of namespaces, Linux is already more like plan9 than classic unix.
– Uncle Billy
Mar 22 at 9:11
@forest Plan 9 is not a "highly specialized" system -- it was supposed to be a general purpose system like Unix or windows (why it failed at replacing Unix and remained a research system is a completely different story). Anyways, just as Linux, plan9 is exposing virtualized interfaces to its hardware (and doesn't have any ioctls -- I don't see how using netlink vs ioctls factor in all this), even if it strives to be more consistent (eg. the network interfaces are accessible via the filesystem). With the introduction of namespaces, Linux is already more like plan9 than classic unix.
– Uncle Billy
Mar 22 at 9:11
1
1
Very nice argument: either there's devfs, which is a filesystem per definition, or there's no devfs, in which case you need a filesystem to host device nodes ...
– pmf
Mar 22 at 14:47
Very nice argument: either there's devfs, which is a filesystem per definition, or there's no devfs, in which case you need a filesystem to host device nodes ...
– pmf
Mar 22 at 14:47
|
show 1 more comment
Peter L. is a new contributor. Be nice, and check out our Code of Conduct.
Peter L. is a new contributor. Be nice, and check out our Code of Conduct.
Peter L. is a new contributor. Be nice, and check out our Code of Conduct.
Peter L. is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f507837%2fdoes-the-linux-kernel-need-a-file-system-to-run%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
4
i think that a running kernel does not "require"
useful exposure to the outside world– jsotola
Mar 21 at 23:28
19
Brings to mind the old halted Linux firewall (circa 2002)
– Jeff Schaller
Mar 22 at 0:50
1
If you add new code to the kernel, you can do anything. If you can't, it will initialize fine up to the point where it tries to run
init(the first user-space process), and that will fail.– immibis
Mar 22 at 6:44
1
Define "run"...
– Thorbjørn Ravn Andersen
Mar 22 at 11:49
Read operating system: three easy pieces
– Basile Starynkevitch
Mar 22 at 12:03