Shachar Shemesh wrote:
Gilad Ben-Yossef wrote:
This approach will allow in the future to throw out all the code in
the kernel that has anything to do with finding the root file system,
mounting NFS as root fs, kernel DHCP and IP setting (aka
autoconfiguration) and replacing them will "early user space" - user
space code compiled and linked against a mini-libc like library called
klibc.
That much I have heard before. What I totally fail to understand is why
this is any different than initrd. Reasons I don't see any difference:
- The kernel did not have to find initrd either - it was loaded by the
boot loader
Which means you need boot loader to support initrd loading. Hell, it
even means you need a boot loader - both of which are not obvious in
embedded systems, for example.
Another similar scenario is when using the newly (for some definition of
newly) feature of kexec - with initrd you need to worry about
allocating, copying and passing the right address to the initrd in case
of a kexec() call, which is possible but a little messy. With initramfs
you don't need to think about it even.
- Initrd contained the code to do all the above too. If there ever was
any such code inside the kernel (and I know that at least DHCP was
there), initrd could have made it redundant anyways.
Tht is true - but because initrd was sometime limiting, it was more
difficult to demand all the users to use it instead of the kernel, so
kernel support for these things stayed in there.
- Iniramfs will save us the need to compile cramfs into the kernel
statically, but instead will require us to compile cpio and tmpfs
statically.
tmpfs is always compiled into the kernel if you want shared memory to
work on your kernel and most of us do. In addition, the initrd data
would actually cause two copies of the data in it to be present in
memory for items in it that are in use - one in the initrd blocks
themselves, one in the page cache for actual use. With initramfs the
entire data sits in the page cache anyway, so it's more conservative of
memory.
- The initramfs would still need to be generated after the kernel is
compiled, or else we go back to requiring an initrd IN ADDITION to the
initramfs, to store all the modules relevant for mounting root.
Yeah, I know. That one bugs me two. I think we need a "update initramfs"
make target for Kbuild. Should be fairly simple to do.
In short, I don't understand why a new technology was necessary.
Hope I've shed light on some of the reasons.
I wonder if enough people are interested in a talk about early user space.
Gilad
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
