[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAN_LGv3Opj9RW0atfXODy-Epn++5mt_DLEi-ewxR9Me5x46Bkg@mail.gmail.com>
Date: Thu, 25 Sep 2025 00:17:39 +0800
From: Alexander Patrakov <patrakov@...il.com>
To: Christophe Leroy <christophe.leroy@...roup.eu>
Cc: Askar Safin <safinaskar@...il.com>, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, 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>, Rob Landley <rob@...dley.net>,
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 00/62] initrd: remove classic initrd support
On Tue, Sep 23, 2025 at 8:22 PM Christophe Leroy
<christophe.leroy@...roup.eu> wrote:
>
>
>
> Le 13/09/2025 à 02:37, Askar Safin a écrit :
> > [Vous ne recevez pas souvent de courriers de safinaskar@...il.com. Découvrez pourquoi ceci est important à https://aka.ms/LearnAboutSenderIdentification ]
> >
> > 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.
>
> Apologise if my question looks stupid, but I'm using QEMU for various
> tests, and the way QEMU is started is something like:
>
> qemu-system-ppc -kernel ./vmlinux -cpu g4 -M mac99 -initrd
> ./qemu/rootfs.cpio.gz
>
> I was therefore expecting (and fearing) it to fail with your series
> applied, but surprisingly it still works.
>
> 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. What you are passing is an initramfs (a gzipped cpio archive
with all the files), which is a modern and supported use case.
--
Alexander Patrakov
Powered by blists - more mailing lists