[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2025013037-feel-strategic-4a25@gregkh>
Date: Thu, 30 Jan 2025 10:52:02 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Nir Lichtman <nir@...htman.org>
Cc: corbet@....net, paulmck@...nel.org, akpm@...ux-foundation.org,
rostedt@...dmis.org, Neeraj.Upadhyay@....com, mcanal@...lia.com,
thuth@...hat.com, ardb@...nel.org, bp@...en8.de,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
rob@...dley.net
Subject: Re: [PATCH] docs: clarify rdinit precedence and correct ramdisk to
initramfs
On Thu, Jan 30, 2025 at 10:59:33AM +0200, Nir Lichtman wrote:
> Problem: Current documentation regarding the init and rdinit params is
> confusing,
> The description of rdinit claims that it is related to ramdisks, even though
> in practice
> It only controls the init executable of the initramfs
> (the deprecated ramdisk mechanism is initialized only after attempting to
> load rdinit
> or its default "/init")
> Rob Landley's document from 2005 "Ramfs, rootfs and initramfs"
> clarifies the distinction between initramfs and ramdisk.
> Another confusing point is that the init param is ignored, in case rdinit or
> "/init"
> exist and are executable in the initramfs; the source code gives priority to
> rdinit.
>
Odd line-wrapping, please fix :(
> Solution: Add more clarification to the kernel params documentation, and fix
> >From ramdisk to initramfs in the rdinit doc.
>
> Signed-off-by: Nir Lichtman <nir@...htman.org>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index fb8752b42ec8..246cb73f71a8 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2182,6 +2182,8 @@
> Format: <full_path>
> Run specified binary instead of /sbin/init as init
> process.
> + Note that rdinit= or /init if rdinit= is not set
> will take
> + precedence in case they are found in the initramfs.
Your patch is also line-wrapped and will not apply at all :(
thanks,
greg k-h
Powered by blists - more mailing lists