[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<1f9aee6090716db537e9911685904786b030111f.camel@cyberus-technology.de>
Date: Sat, 13 Sep 2025 08:58:34 +0000
From: Julian Stecklina <julian.stecklina@...erus-technology.de>
To: "safinaskar@...il.com" <safinaskar@...il.com>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: "tytso@....edu" <tytso@....edu>, "linux-csky@...r.kernel.org"
<linux-csky@...r.kernel.org>, "linux-arch@...r.kernel.org"
<linux-arch@...r.kernel.org>, "rob@...dley.net" <rob@...dley.net>,
"linux-snps-arc@...ts.infradead.org" <linux-snps-arc@...ts.infradead.org>,
"mzxreary@...inter.de" <mzxreary@...inter.de>, "viro@...iv.linux.org.uk"
<viro@...iv.linux.org.uk>, "jack@...e.cz" <jack@...e.cz>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>, "axboe@...nel.dk"
<axboe@...nel.dk>, "linux-riscv@...ts.infradead.org"
<linux-riscv@...ts.infradead.org>, "hch@....de" <hch@....de>,
"thomas.weissschuh@...utronix.de" <thomas.weissschuh@...utronix.de>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
"linux-openrisc@...r.kernel.org" <linux-openrisc@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>, "x86@...nel.org"
<x86@...nel.org>, "kees@...nel.org" <kees@...nel.org>,
"linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>,
"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
"hsiangkao@...ux.alibaba.com" <hsiangkao@...ux.alibaba.com>,
"mcgrof@...nel.org" <mcgrof@...nel.org>, "linux-efi@...r.kernel.org"
<linux-efi@...r.kernel.org>, "cyphar@...har.com" <cyphar@...har.com>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"hca@...ux.ibm.com" <hca@...ux.ibm.com>, "linux-m68k@...ts.linux-m68k.org"
<linux-m68k@...ts.linux-m68k.org>, "monstr@...str.eu" <monstr@...str.eu>,
"andy.shevchenko@...il.com" <andy.shevchenko@...il.com>, "graf@...zon.com"
<graf@...zon.com>, "brauner@...nel.org" <brauner@...nel.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"email2tema@...il.com" <email2tema@...il.com>, "linux-sh@...r.kernel.org"
<linux-sh@...r.kernel.org>, "sparclinux@...r.kernel.org"
<sparclinux@...r.kernel.org>, "ecurtin@...hat.com" <ecurtin@...hat.com>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "linux-hexagon@...r.kernel.org"
<linux-hexagon@...r.kernel.org>, "linux-alpha@...r.kernel.org"
<linux-alpha@...r.kernel.org>, "linux-um@...ts.infradead.org"
<linux-um@...ts.infradead.org>, "mingo@...hat.com" <mingo@...hat.com>,
"loongarch@...ts.linux.dev" <loongarch@...ts.linux.dev>,
"initramfs@...r.kernel.org" <initramfs@...r.kernel.org>,
"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"patches@...ts.linux.dev" <patches@...ts.linux.dev>,
"thorsten.blum@...ux.dev" <thorsten.blum@...ux.dev>
Subject: Re: [PATCH RESEND 00/62] initrd: remove classic initrd support
On Sat, 2025-09-13 at 00:37 +0000, Askar Safin wrote:
> Intro
> ====
> This patchset removes classic initrd (initial RAM disk) support,
> which was deprecated in 2020.
> Initramfs still stays, and RAM disk itself (brd) still stays, too.
> init/do_mounts* and init/*initramfs* are listed in VFS entry in
> MAINTAINERS, so I think this patchset should go through VFS tree.
> This patchset touchs every subdirectory in arch/, so I tested it
> on 8 (!!!) archs in Qemu (see details below).
> Warning: this patchset renames CONFIG_BLK_DEV_INITRD (!!!) to CONFIG_INITRAMFS
> and CONFIG_RD_* to CONFIG_INITRAMFS_DECOMPRESS_* (for example,
> CONFIG_RD_GZIP to CONFIG_INITRAMFS_DECOMPRESS_GZIP).
> If you still use initrd, see below for workaround.
>
As the person who kicked this off by trying to get erofs support for initrds:
You have all my support for nuking so much legacy code! I'm all for removing
historical baggage even if it comes with slight inconveniences for fringe
usecase users (me!).
If this series goes through, I'll drink a beer to you!
Acked-by: Julian Stecklina <julian.stecklina@...erus-technology.de>
>
> Also I renamed CONFIG_BLK_DEV_INITRD (which became total misnomer)
> to CONFIG_INITRAMFS. And CONFIG_RD_* to CONFIG_INITRAMFS_DECOMPRESS_*.
> This will break all configs out there (update your configs!).
This is beautiful. The original names were pretty misleading!
> Workaround
> ====
> If "retain_initrd" is passed to kernel, then initramfs/initrd,
> passed by bootloader, is retained and becomes available after boot
> as read-only magic file /sys/firmware/initrd [3].
This is pretty neat, because now you can use _all filesystems_ as initrds. :-D
This solves my original problem, albeit with a tiny shim initramfs. Nice!
Julian
Powered by blists - more mailing lists