On 9/24/25 11:17, Alexander Patrakov wrote:
Therefore is it really initrd you are removing or just some corner case
? If it is really initrd, then how does QEMU still work with that
-initrd parameter ?
The QEMU -initrd parameter is a misnomer. It can be used to pass an
initrd or an initramfs, and the kernel automatically figures out what
it is.
It's not a misnomer, initrams has always been able to make use of the
existing initrd loading mechanism to read images externally supplied by
the bootloader. It's what grub calls it too. I documented it in the
"External initramfs images" section of
https://kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt
back in 2005. The mechanism itself is 30 years old
(Documentation/initrd.txt was written by Werner Almsberger in linux
1.3.73 from March 7, 1996, ala
https://github.com/mpe/linux-fullhistory/commit/afc106342783 ).
Since initrd contents could always be in a bunch of different
autodetected formats (and optionally compressed just like the kernel),
initramfs just hooked in to the staircase and said "if the format is
cpio, call this function to handle it". The patch series proposes
removing all the other formats, but not otherwise changing the existing
external image loader mechanism. (Personally I think removing the
architecture-specific hacks but leaving the generic support under init/
would probably have made more sense as a first step.)
The bootloader hands off an initrd image, initramfs is the boot-time
cpio extraction plumbing that's _init tagged and gets freed, and rootfs
is the persistent mounted instance of ramfs or tmpfs that's always there
and is analogous to the init task (PID 1) except for the mount tree.
(And is often overmounted so it's not visible, but it's still there. And
is NOT SPECIAL: overmounts aren't a new concept, nor is hiding them in
things like "df".)
There's a REASON my documentation file was called
ramfs-rootfs-initramfs.txt: the naming's always been a bit... layered.
(And yes, I have always spelled initmpfs with only one t.)
Rob
_______________________________________________
linux-snps-arc mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
