From: "Nir Lichtman" <nir@lichtman.org>
To: <pmladek@suse.com>, <vbabka@suse.cz>, <paul@paul-moore.com>,
<rrangel@chromium.org>, <hyeonggon.yoo@sk.com>,
<kpsingh@kernel.org>, <urezki@gmail.com>,
<linux-kernel@vger.kernel.org>
Subject: [PATCH] init: remove legacy lilo auto cmdline hack
Date: Sun, 26 Jan 2025 11:52:30 +0200 [thread overview]
Message-ID: <003601db6fd8$05655e30$10301a90$@lichtman.org> (raw)
Problem: The code handling the "init" and "initrd" command line options has
a
LILO specific hack which cleans up arguments that are meant to be passed to
init.
As the comment claims, LILO indeed passes "auto" to the init to signify that
the
boot was automatic without user manual intervention, but I think this logic
is weird
and unexpected since it just cleans up everything that came before the
"init=" or "initrd="
which could be confusing for the end users expecting the unknown params to
be passed on
to the init process, but they just get swallowed because of this.
On top of that, LILO is pretty much an abandoned project, so I don't think
there is much
value of having this handling code in the kernel.
Example: This behavior can be demonstrated by running
qemu-system-x86_64 -kernel arch/x86/boot/bzImage -append "arg1 init=/myinit"
The LILO logic will clean up the arg1, such that no arguments are passed to
myinit
Solution: Remove this logic from the "init=" and "initrd=" handling logic
Signed-off-by: Nir Lichtman <nir@lichtman.org>
---
init/main.c | 15 ---------------
1 file changed, 15 deletions(-)
diff --git a/init/main.c b/init/main.c
index 893cb77aef22..864b60a07b90 100644
--- a/init/main.c
+++ b/init/main.c
@@ -589,29 +589,14 @@ static int __init unknown_bootoption(char *param, char
*val,
static int __init init_setup(char *str)
{
- unsigned int i;
-
execute_command = str;
- /*
- * In case LILO is going to boot us with default command line,
- * it prepends "auto" before the whole cmdline which makes
- * the shell think it should execute a script with such name.
- * So we ignore all arguments entered _before_ init=... [MJ]
- */
- for (i = 1; i < MAX_INIT_ARGS; i++)
- argv_init[i] = NULL;
return 1;
}
__setup("init=", init_setup);
static int __init rdinit_setup(char *str)
{
- unsigned int i;
-
ramdisk_execute_command = str;
- /* See "auto" comment in init_setup */
- for (i = 1; i < MAX_INIT_ARGS; i++)
- argv_init[i] = NULL;
return 1;
}
__setup("rdinit=", rdinit_setup);
--
2.39.5
reply other threads:[~2025-01-26 9:59 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='003601db6fd8$05655e30$10301a90$@lichtman.org' \
--to=nir@lichtman.org \
--cc=hyeonggon.yoo@sk.com \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=pmladek@suse.com \
--cc=rrangel@chromium.org \
--cc=urezki@gmail.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®