Message-ID: <8f595eec-e85e-4c1f-acb0-5069a01c1012@landley.net>
Date: Mon, 15 Sep 2025 16:05:14 -0500
From: Rob Landley <rob@...dley.net>
To: Askar Safin <safinaskar@...il.com>, linux-fsdevel@...r.kernel.org,
 linux-kernel@...r.kernel.org
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Christian Brauner <brauner@...nel.org>, Al Viro <viro@...iv.linux.org.uk>,
 Jan Kara <jack@...e.cz>, Christoph Hellwig <hch@....de>,
 Jens Axboe <axboe@...nel.dk>, Andy Shevchenko <andy.shevchenko@...il.com>,
 Aleksa Sarai <cyphar@...har.com>,
 Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
 Julian Stecklina <julian.stecklina@...erus-technology.de>,
 Gao Xiang <hsiangkao@...ux.alibaba.com>, Art Nikpal <email2tema@...il.com>,
 Andrew Morton <akpm@...ux-foundation.org>, Eric Curtin <ecurtin@...hat.com>,
 Alexander Graf <graf@...zon.com>, Lennart Poettering <mzxreary@...inter.de>,
 linux-arch@...r.kernel.org, linux-alpha@...r.kernel.org,
 linux-snps-arc@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org,
 linux-csky@...r.kernel.org, linux-hexagon@...r.kernel.org,
 loongarch@...ts.linux.dev, linux-m68k@...ts.linux-m68k.org,
 linux-mips@...r.kernel.org, linux-openrisc@...r.kernel.org,
 linux-parisc@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
 linux-riscv@...ts.infradead.org, linux-s390@...r.kernel.org,
 linux-sh@...r.kernel.org, sparclinux@...r.kernel.org,
 linux-um@...ts.infradead.org, x86@...nel.org, Ingo Molnar
 <mingo@...hat.com>, linux-block@...r.kernel.org, initramfs@...r.kernel.org,
 linux-api@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-efi@...r.kernel.org, linux-ext4@...r.kernel.org,
 "Theodore Y . Ts'o" <tytso@....edu>, linux-acpi@...r.kernel.org,
 Michal Simek <monstr@...str.eu>, devicetree@...r.kernel.org,
 Luis Chamberlain <mcgrof@...nel.org>, Kees Cook <kees@...nel.org>,
 Thorsten Blum <thorsten.blum@...ux.dev>, Heiko Carstens <hca@...ux.ibm.com>,
 patches@...ts.linux.dev
Subject: Re: [PATCH RESEND 17/62] doc: modernize
 Documentation/filesystems/ramfs-rootfs-initramfs.rst

On 9/12/25 19:37, Askar Safin wrote:
> Update it to reflect initrd removal.
> 
> Also I specified that error reports should
> go to linux-doc@...r.kernel.org , because
> Rob Landley said that he keeps getting
> reports about this document and is unable
> to fix them

Do you think emailing a list I could forward stuff to will improve matters?

I find the community an elaborate bureaucracy unresponsive to hobbyists. 
Documentation/process/submitting-patches.rst being a 934 line document 
with a bibliography, plus a 24 step checklist not counting the a) b) c) 
subsections are just symptoms. The real problem is following those is 
not sufficient to navigate said bureaucracy.

>   What is ramfs?
>   --------------
>   
> @@ -101,9 +103,9 @@ archive is extracted into it, the kernel will fall through to the older code
>   to locate and mount a root partition, then exec some variant of /sbin/init
>   out of that.
>   
> -All this differs from the old initrd in several ways:
> +All this differs from the old initrd (removed in 2025) in several ways:

Why keep the section when you removed the old mechanism? You took away 
their choices, you don't need to sell them on it.

(Unless you're trying to sell them on using a current linux kernel 
rather than 2.6 or bsd or qnx or something. But if they _do_ remove 32 
bit support, or stick a rust dependency in the base build, I suspect 
that ship has sailed...)

> -  - The old initrd was always a separate file, while the initramfs archive is
> +  - The old initrd was always a separate file, while the initramfs archive can be
>       linked into the linux kernel image.  (The directory ``linux-*/usr`` is
>       devoted to generating this archive during the build.)
>   
> @@ -137,7 +139,7 @@ Populating initramfs:
>   
>   The 2.6 kernel build process always creates a gzipped cpio format initramfs
>   archive and links it into the resulting kernel binary.  By default, this
> -archive is empty (consuming 134 bytes on x86).
> +archive is nearly empty (consuming 134 bytes on x86).

Those two lines you just touched contradict each other.

For historical reference, commit c33df4eaaf41 in 2007 added a second 
codepath to special case NOT having an initramfs, for some reason. 
That's how static linked cpio in the kernel image and external initrd= 
loaded cpio from the bootloader wound up having different behavior.

The init/noinitramfs.c file does init/mkdir("/dev") and 
init_mknod("/dev/console") because calling the syscall_blah() functions 
directly was considered icky so they created gratuitous wrappers to do 
it for you instead, because that's cleaner somehow. (Presumably the same 
logic as C++ having get and set methods that perform a simple assignment 
and return a value. Because YOU can't be trusted to touch MY code.)

Note that ONLY init/noinitramfs.c creates /dev/console. You'd THINK the 
logical thing to do would be to detect failure of the filp_open() in 
console_on_rootfs() and do the mkdir/mknod there and retry (since that's 
__init code too), but no...

My VERY vague recollection from back in the dark ages is if you didn't 
specify any INITRAMFS_SOURCE in kconfig then gen_init_cpio got called 
with no arguments and spit out a "usage" section that got interpreted as 
scripts/gen_initramfs_list.sh output, back when the plumbing ignored 
lines it didn't understand but there was an "example: a simple 
initramfs" section in the usage with "dir /dev" and "nod /dev/console" 
lines that created a cpio archive with /dev/console in it which would 
get statically linked in as a "default", and code reached out and used 
this because it was there without understanding WHY it was there. So it 
initially worked by coincidence, and rather than make it explicit they 
went "two codepaths, half the testing!" and thus...

Anyway, that's why the 130+ byte archive was there. It wasn't actually 
empty, even when initramfs was disabled.

One of the "cleanups that didn't actually fix it" was 
https://github.com/mpe/linux-fullhistory/commit/2bd3a997befc if you want 
to dig into the history yourself. I wrote my docs in 2005 and that was 
2010 so "somewhere in there"...

> -If the kernel has initrd support enabled, an external cpio.gz archive can also
> -be passed into a 2.6 kernel in place of an initrd.  In this case, the kernel
> -will autodetect the type (initramfs, not initrd) and extract the external cpio
> +If the kernel has CONFIG_BLK_DEV_INITRD enabled, an external cpio.gz archive can also

You renamed that symbol, then even you use the old name here.

> +be passed into a 2.6 kernel.  In this case, the kernel will extract the external cpio
>   archive into rootfs before trying to run /init.
>   
> -This has the memory efficiency advantages of initramfs (no ramdisk block
> -device) but the separate packaging of initrd (which is nice if you have
> +This is nice if you have
>   non-GPL code you'd like to run from initramfs, without conflating it with
> -the GPL licensed Linux kernel binary).
> +the GPL licensed Linux kernel binary.

IANAL: Whether or not this qualifies as "mere aggregation" had yet to go 
to court last I heard.

Which is basically why 
https://hackmd.io/@starnight/Load_Firmware_Files_Later_in_Linux_Kernel 
was so screwed up in the first place: the logical thing to do would be 
put the firmware in a static initramfs and have the module 
initialization happen after initramfs was populated... BUT LICENSING! We 
must have a much more complicated implementation because license. I 
believe I suggested passing said initramfs in via the initrd mechanism 
so it remains a separate file until boot time, and was ignored. *shrug* 
The usual...

>   It can also be used to supplement the kernel's built-in initramfs image.  The
>   files in the external archive will overwrite any conflicting files in
> @@ -278,7 +278,7 @@ User Mode Linux, like so::
>     EOF
>     gcc -static hello.c -o init
>     echo init | cpio -o -H newc | gzip > test.cpio.gz
> -  # Testing external initramfs using the initrd loading mechanism.
> +  # Testing external initramfs.

Does grub not still call it "initrd"?

>     qemu -kernel /boot/vmlinuz -initrd test.cpio.gz /dev/zero

A) they added -hda so you don't have to give it a dummy /dev/zero anymore.

B) there's no longer a "qemu" defaulting to the current architecture, 
you have to explicitly specify qemu-system-blah unless you create the 
symlink yourself by hand. This was considered an "improvement" by IBM 
bureaucrats. (Not a regression, a "feature". Oh well...)

C) to be honest I'd just point people at mkroot for examples these days, 
but I'm biased. (It smells like me.)

Rob

Powered by blists - more mailing lists