Why kernel cannot do the initrd/initramfs job itself? [closed]
Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
Currently I am learning about linux booting process.Here i noticed that the initrd will create temporary root file system that includes drivers(LVM, NFS, etc) which are required by kernel.After that kernel will make use of that drivers and it will mount real root file system.
Here my question is why not kernel itself should include the necessary drivers inside it and why it depends on initrd ?
boot linux-kernel initramfs initrd
closed as primarily opinion-based by Rui F Ribeiro, SatÃ
 Katsura, Kiwy, Archemar, Jesse_b May 9 at 16:55
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |Â
up vote
2
down vote
favorite
Currently I am learning about linux booting process.Here i noticed that the initrd will create temporary root file system that includes drivers(LVM, NFS, etc) which are required by kernel.After that kernel will make use of that drivers and it will mount real root file system.
Here my question is why not kernel itself should include the necessary drivers inside it and why it depends on initrd ?
boot linux-kernel initramfs initrd
closed as primarily opinion-based by Rui F Ribeiro, SatÃ
 Katsura, Kiwy, Archemar, Jesse_b May 9 at 16:55
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
1
How useful are those things after the system has come up?
â Ignacio Vazquez-Abrams
May 8 at 6:25
could you please elaborate your question ? @ Ignacio Vazquez-Abrams
â Abdulvakaf K
May 8 at 6:43
Build all the modules that would normally be inside initrd statically into the kernel. The reason it is not done this way is that it is easier to manage the shared modules, hence the initrd method is a convenience to load modules that are not normally built into the kernel.
â GracefulRestart
May 8 at 6:49
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
Currently I am learning about linux booting process.Here i noticed that the initrd will create temporary root file system that includes drivers(LVM, NFS, etc) which are required by kernel.After that kernel will make use of that drivers and it will mount real root file system.
Here my question is why not kernel itself should include the necessary drivers inside it and why it depends on initrd ?
boot linux-kernel initramfs initrd
Currently I am learning about linux booting process.Here i noticed that the initrd will create temporary root file system that includes drivers(LVM, NFS, etc) which are required by kernel.After that kernel will make use of that drivers and it will mount real root file system.
Here my question is why not kernel itself should include the necessary drivers inside it and why it depends on initrd ?
boot linux-kernel initramfs initrd
asked May 8 at 6:21
Abdulvakaf K
294
294
closed as primarily opinion-based by Rui F Ribeiro, SatÃ
 Katsura, Kiwy, Archemar, Jesse_b May 9 at 16:55
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as primarily opinion-based by Rui F Ribeiro, SatÃ
 Katsura, Kiwy, Archemar, Jesse_b May 9 at 16:55
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
1
How useful are those things after the system has come up?
â Ignacio Vazquez-Abrams
May 8 at 6:25
could you please elaborate your question ? @ Ignacio Vazquez-Abrams
â Abdulvakaf K
May 8 at 6:43
Build all the modules that would normally be inside initrd statically into the kernel. The reason it is not done this way is that it is easier to manage the shared modules, hence the initrd method is a convenience to load modules that are not normally built into the kernel.
â GracefulRestart
May 8 at 6:49
add a comment |Â
1
How useful are those things after the system has come up?
â Ignacio Vazquez-Abrams
May 8 at 6:25
could you please elaborate your question ? @ Ignacio Vazquez-Abrams
â Abdulvakaf K
May 8 at 6:43
Build all the modules that would normally be inside initrd statically into the kernel. The reason it is not done this way is that it is easier to manage the shared modules, hence the initrd method is a convenience to load modules that are not normally built into the kernel.
â GracefulRestart
May 8 at 6:49
1
1
How useful are those things after the system has come up?
â Ignacio Vazquez-Abrams
May 8 at 6:25
How useful are those things after the system has come up?
â Ignacio Vazquez-Abrams
May 8 at 6:25
could you please elaborate your question ? @ Ignacio Vazquez-Abrams
â Abdulvakaf K
May 8 at 6:43
could you please elaborate your question ? @ Ignacio Vazquez-Abrams
â Abdulvakaf K
May 8 at 6:43
Build all the modules that would normally be inside initrd statically into the kernel. The reason it is not done this way is that it is easier to manage the shared modules, hence the initrd method is a convenience to load modules that are not normally built into the kernel.
â GracefulRestart
May 8 at 6:49
Build all the modules that would normally be inside initrd statically into the kernel. The reason it is not done this way is that it is easier to manage the shared modules, hence the initrd method is a convenience to load modules that are not normally built into the kernel.
â GracefulRestart
May 8 at 6:49
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
3
down vote
accepted
See also answers on these questions:
- Why don't we include File System drivers in the kernel itself instead of using Initrd/Initramfs
- Why do we need initramfs and initrd
1. Why not kernel itself should include the necessary drivers inside it
Firstly, know that kernel memory is not demand-paged. That would be a circular dependency. If you page out your disk driver to the disk when you're low on memory, you can't load it back later.
(And inside the Linux kernel, we don't try to define some higher layer which isn't involved in the storage path and can safely be paged out. Allegedly this is possible: Windows did it. I don't know what this higher layer is supposed to be though. Maybe it is defined dynamically. Or maybe Windows has the luxury of not supporting strange ideas like swap-over-NFS).
Instead, we support loading modules. If we don't need NFS on this particular computer, we don't have to load it.
In a modern distribution this saves on the order of a hundred megabytes of RAM overall. (Look at the space taken by /lib/modules/$VERSION/
. Note that in modern distributions, the modules are compressed e.g. .xz
files).
2. and why it depends on initrd
While kernel modules are the more obvious reason for the initrd, there is a second aspect.
It lets userspace build arbitrarily complex storage stacks to access the root filesystem. E.g. getting an IP address using DHCP, to support NFS, or prompting for a disk encryption passphrase.
Again, the kernel tries not to bloat too much e.g. with user interface code.
Memory usage is only one reason. The kernel/userspace division is overloaded with a number of purposes. E.g. the kernel can be one project and work specifically on kernel things. Userspace can be anything; it could be a "normal" Linux distribution, or it could be an entirely independent project like the Android OS.
This is different from other OS's, e.g. the BSDs maintain kernel + core userspace together. This is illustrated by BSDs being able to handle the 2038 problem with a single flag day conversion of both kernel and userspace.
add a comment |Â
up vote
1
down vote
It doesn't if you want to embed the drivers within the kernel. A great source based linux distribution that can help with using a custom kernel configuration would be Gentoo
or you can simply use the current distributions package manager to acquire the Linux Kernel Source (usually a dev and headers package) and use the make config
to step through the required hardware required for the target system and change each value from M
to *
.
More detailed instructions can be found in the documentation
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
See also answers on these questions:
- Why don't we include File System drivers in the kernel itself instead of using Initrd/Initramfs
- Why do we need initramfs and initrd
1. Why not kernel itself should include the necessary drivers inside it
Firstly, know that kernel memory is not demand-paged. That would be a circular dependency. If you page out your disk driver to the disk when you're low on memory, you can't load it back later.
(And inside the Linux kernel, we don't try to define some higher layer which isn't involved in the storage path and can safely be paged out. Allegedly this is possible: Windows did it. I don't know what this higher layer is supposed to be though. Maybe it is defined dynamically. Or maybe Windows has the luxury of not supporting strange ideas like swap-over-NFS).
Instead, we support loading modules. If we don't need NFS on this particular computer, we don't have to load it.
In a modern distribution this saves on the order of a hundred megabytes of RAM overall. (Look at the space taken by /lib/modules/$VERSION/
. Note that in modern distributions, the modules are compressed e.g. .xz
files).
2. and why it depends on initrd
While kernel modules are the more obvious reason for the initrd, there is a second aspect.
It lets userspace build arbitrarily complex storage stacks to access the root filesystem. E.g. getting an IP address using DHCP, to support NFS, or prompting for a disk encryption passphrase.
Again, the kernel tries not to bloat too much e.g. with user interface code.
Memory usage is only one reason. The kernel/userspace division is overloaded with a number of purposes. E.g. the kernel can be one project and work specifically on kernel things. Userspace can be anything; it could be a "normal" Linux distribution, or it could be an entirely independent project like the Android OS.
This is different from other OS's, e.g. the BSDs maintain kernel + core userspace together. This is illustrated by BSDs being able to handle the 2038 problem with a single flag day conversion of both kernel and userspace.
add a comment |Â
up vote
3
down vote
accepted
See also answers on these questions:
- Why don't we include File System drivers in the kernel itself instead of using Initrd/Initramfs
- Why do we need initramfs and initrd
1. Why not kernel itself should include the necessary drivers inside it
Firstly, know that kernel memory is not demand-paged. That would be a circular dependency. If you page out your disk driver to the disk when you're low on memory, you can't load it back later.
(And inside the Linux kernel, we don't try to define some higher layer which isn't involved in the storage path and can safely be paged out. Allegedly this is possible: Windows did it. I don't know what this higher layer is supposed to be though. Maybe it is defined dynamically. Or maybe Windows has the luxury of not supporting strange ideas like swap-over-NFS).
Instead, we support loading modules. If we don't need NFS on this particular computer, we don't have to load it.
In a modern distribution this saves on the order of a hundred megabytes of RAM overall. (Look at the space taken by /lib/modules/$VERSION/
. Note that in modern distributions, the modules are compressed e.g. .xz
files).
2. and why it depends on initrd
While kernel modules are the more obvious reason for the initrd, there is a second aspect.
It lets userspace build arbitrarily complex storage stacks to access the root filesystem. E.g. getting an IP address using DHCP, to support NFS, or prompting for a disk encryption passphrase.
Again, the kernel tries not to bloat too much e.g. with user interface code.
Memory usage is only one reason. The kernel/userspace division is overloaded with a number of purposes. E.g. the kernel can be one project and work specifically on kernel things. Userspace can be anything; it could be a "normal" Linux distribution, or it could be an entirely independent project like the Android OS.
This is different from other OS's, e.g. the BSDs maintain kernel + core userspace together. This is illustrated by BSDs being able to handle the 2038 problem with a single flag day conversion of both kernel and userspace.
add a comment |Â
up vote
3
down vote
accepted
up vote
3
down vote
accepted
See also answers on these questions:
- Why don't we include File System drivers in the kernel itself instead of using Initrd/Initramfs
- Why do we need initramfs and initrd
1. Why not kernel itself should include the necessary drivers inside it
Firstly, know that kernel memory is not demand-paged. That would be a circular dependency. If you page out your disk driver to the disk when you're low on memory, you can't load it back later.
(And inside the Linux kernel, we don't try to define some higher layer which isn't involved in the storage path and can safely be paged out. Allegedly this is possible: Windows did it. I don't know what this higher layer is supposed to be though. Maybe it is defined dynamically. Or maybe Windows has the luxury of not supporting strange ideas like swap-over-NFS).
Instead, we support loading modules. If we don't need NFS on this particular computer, we don't have to load it.
In a modern distribution this saves on the order of a hundred megabytes of RAM overall. (Look at the space taken by /lib/modules/$VERSION/
. Note that in modern distributions, the modules are compressed e.g. .xz
files).
2. and why it depends on initrd
While kernel modules are the more obvious reason for the initrd, there is a second aspect.
It lets userspace build arbitrarily complex storage stacks to access the root filesystem. E.g. getting an IP address using DHCP, to support NFS, or prompting for a disk encryption passphrase.
Again, the kernel tries not to bloat too much e.g. with user interface code.
Memory usage is only one reason. The kernel/userspace division is overloaded with a number of purposes. E.g. the kernel can be one project and work specifically on kernel things. Userspace can be anything; it could be a "normal" Linux distribution, or it could be an entirely independent project like the Android OS.
This is different from other OS's, e.g. the BSDs maintain kernel + core userspace together. This is illustrated by BSDs being able to handle the 2038 problem with a single flag day conversion of both kernel and userspace.
See also answers on these questions:
- Why don't we include File System drivers in the kernel itself instead of using Initrd/Initramfs
- Why do we need initramfs and initrd
1. Why not kernel itself should include the necessary drivers inside it
Firstly, know that kernel memory is not demand-paged. That would be a circular dependency. If you page out your disk driver to the disk when you're low on memory, you can't load it back later.
(And inside the Linux kernel, we don't try to define some higher layer which isn't involved in the storage path and can safely be paged out. Allegedly this is possible: Windows did it. I don't know what this higher layer is supposed to be though. Maybe it is defined dynamically. Or maybe Windows has the luxury of not supporting strange ideas like swap-over-NFS).
Instead, we support loading modules. If we don't need NFS on this particular computer, we don't have to load it.
In a modern distribution this saves on the order of a hundred megabytes of RAM overall. (Look at the space taken by /lib/modules/$VERSION/
. Note that in modern distributions, the modules are compressed e.g. .xz
files).
2. and why it depends on initrd
While kernel modules are the more obvious reason for the initrd, there is a second aspect.
It lets userspace build arbitrarily complex storage stacks to access the root filesystem. E.g. getting an IP address using DHCP, to support NFS, or prompting for a disk encryption passphrase.
Again, the kernel tries not to bloat too much e.g. with user interface code.
Memory usage is only one reason. The kernel/userspace division is overloaded with a number of purposes. E.g. the kernel can be one project and work specifically on kernel things. Userspace can be anything; it could be a "normal" Linux distribution, or it could be an entirely independent project like the Android OS.
This is different from other OS's, e.g. the BSDs maintain kernel + core userspace together. This is illustrated by BSDs being able to handle the 2038 problem with a single flag day conversion of both kernel and userspace.
edited May 8 at 8:29
answered May 8 at 8:06
sourcejedi
18.2k32475
18.2k32475
add a comment |Â
add a comment |Â
up vote
1
down vote
It doesn't if you want to embed the drivers within the kernel. A great source based linux distribution that can help with using a custom kernel configuration would be Gentoo
or you can simply use the current distributions package manager to acquire the Linux Kernel Source (usually a dev and headers package) and use the make config
to step through the required hardware required for the target system and change each value from M
to *
.
More detailed instructions can be found in the documentation
add a comment |Â
up vote
1
down vote
It doesn't if you want to embed the drivers within the kernel. A great source based linux distribution that can help with using a custom kernel configuration would be Gentoo
or you can simply use the current distributions package manager to acquire the Linux Kernel Source (usually a dev and headers package) and use the make config
to step through the required hardware required for the target system and change each value from M
to *
.
More detailed instructions can be found in the documentation
add a comment |Â
up vote
1
down vote
up vote
1
down vote
It doesn't if you want to embed the drivers within the kernel. A great source based linux distribution that can help with using a custom kernel configuration would be Gentoo
or you can simply use the current distributions package manager to acquire the Linux Kernel Source (usually a dev and headers package) and use the make config
to step through the required hardware required for the target system and change each value from M
to *
.
More detailed instructions can be found in the documentation
It doesn't if you want to embed the drivers within the kernel. A great source based linux distribution that can help with using a custom kernel configuration would be Gentoo
or you can simply use the current distributions package manager to acquire the Linux Kernel Source (usually a dev and headers package) and use the make config
to step through the required hardware required for the target system and change each value from M
to *
.
More detailed instructions can be found in the documentation
answered May 8 at 6:52
jas-
71038
71038
add a comment |Â
add a comment |Â
1
How useful are those things after the system has come up?
â Ignacio Vazquez-Abrams
May 8 at 6:25
could you please elaborate your question ? @ Ignacio Vazquez-Abrams
â Abdulvakaf K
May 8 at 6:43
Build all the modules that would normally be inside initrd statically into the kernel. The reason it is not done this way is that it is easier to manage the shared modules, hence the initrd method is a convenience to load modules that are not normally built into the kernel.
â GracefulRestart
May 8 at 6:49