This updates the x86 code to use the CONFIG_GENERIC_CMDLINE
option.
Cc: xe-linux-external@cisco.com
Signed-off-by: Ruslan Ruslichenko <rruslich@cisco.com>
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@gmail.com>
Signed-off-by: Daniel Walker <danielwa@cisco.com>
---
arch/x86/Kconfig | 44 +----------------------------------------
arch/x86/kernel/setup.c | 18 ++---------------
2 files changed, 3 insertions(+), 59 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 66bfabae8814..390ffaa743df 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -145,6 +145,7 @@ config X86
select EDAC_SUPPORT
select GENERIC_CLOCKEVENTS_BROADCAST if X86_64 || (X86_32 && X86_LOCAL_APIC)
select GENERIC_CLOCKEVENTS_MIN_ADJUST
+ select GENERIC_CMDLINE
select GENERIC_CMOS_UPDATE
select GENERIC_CPU_AUTOPROBE
select GENERIC_CPU_VULNERABILITIES
@@ -2309,49 +2310,6 @@ choice
endchoice
-config CMDLINE_BOOL
- bool "Built-in kernel command line"
- help
- Allow for specifying boot arguments to the kernel at
- build time. On some systems (e.g. embedded ones), it is
- necessary or convenient to provide some or all of the
- kernel boot arguments with the kernel itself (that is,
- to not rely on the boot loader to provide them.)
-
- To compile command line arguments into the kernel,
- set this option to 'Y', then fill in the
- boot arguments in CONFIG_CMDLINE.
-
- Systems with fully functional boot loaders (i.e. non-embedded)
- should leave this option set to 'N'.
-
-config CMDLINE
- string "Built-in kernel command string"
- depends on CMDLINE_BOOL
- default ""
- help
- Enter arguments here that should be compiled into the kernel
- image and used at boot time. If the boot loader provides a
- command line at boot time, it is appended to this string to
- form the full kernel command line, when the system boots.
-
- However, you can use the CONFIG_CMDLINE_OVERRIDE option to
- change this behavior.
-
- In most cases, the command line (whether built-in or provided
- by the boot loader) should specify the device for the root
- file system.
-
-config CMDLINE_OVERRIDE
- bool "Built-in command line overrides boot loader arguments"
- depends on CMDLINE_BOOL && CMDLINE != ""
- help
- Set this option to 'Y' to have the kernel ignore the boot loader
- command line, and use ONLY the built-in command line.
-
- This is used to work around broken boot loaders. This should
- be set to 'N' under normal conditions.
-
config MODIFY_LDT_SYSCALL
bool "Enable the LDT (local descriptor table)" if EXPERT
default y
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index b098b1fa2470..bd025c003f32 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -55,6 +55,7 @@
#include <asm/unwind.h>
#include <asm/vsyscall.h>
#include <linux/vmalloc.h>
+#include <linux/cmdline.h>
/*
* max_low_pfn_mapped: highest directly mapped pfn < 4 GB
@@ -162,9 +163,6 @@ unsigned long saved_video_mode;
#define RAMDISK_LOAD_FLAG 0x4000
static char __initdata command_line[COMMAND_LINE_SIZE];
-#ifdef CONFIG_CMDLINE_BOOL
-static char __initdata builtin_cmdline[COMMAND_LINE_SIZE] = CONFIG_CMDLINE;
-#endif
#if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
struct edd edd;
@@ -959,19 +957,7 @@ void __init setup_arch(char **cmdline_p)
bss_resource.start = __pa_symbol(__bss_start);
bss_resource.end = __pa_symbol(__bss_stop)-1;
-#ifdef CONFIG_CMDLINE_BOOL
-#ifdef CONFIG_CMDLINE_OVERRIDE
- strscpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
-#else
- if (builtin_cmdline[0]) {
- /* append boot loader cmdline to builtin */
- strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
- strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
- strscpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
- }
-#endif
-#endif
-
+ cmdline_add_builtin(boot_command_line);
strscpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
*cmdline_p = command_line;
--
2.39.2On 11/9/23 17:38, Daniel Walker wrote: > arch/x86/Kconfig | 44 +---------------------------------------- > arch/x86/kernel/setup.c | 18 ++--------------- > 2 files changed, 3 insertions(+), 59 deletions(-) It would be really nice if you managed to get this rebased on current upstream and sent out again. I'd certainly ack the x86 bits if the Kconfig issue that 0day found was fixed up. Also, one nit on the cover letter: > There are a number of people who have expressed interest in these > patches either by asking for them to be merge or testing them. If > people are so inclined please continue to request them to be merge > or to ask the status of the next release. It's helpful to motivate me to > release them again and for the maintainers to see the interest > generated. The way I'd suggest going about getting this merged is to solicit reviews and testing from folks and then get those annotations into the patches. As it stands, this series has zero tags in addition to the SoB tags which I assume were its authors.
On Thu, Oct 02, 2025 at 01:49:39PM -0700, Dave Hansen wrote: > On 11/9/23 17:38, Daniel Walker wrote: > > arch/x86/Kconfig | 44 +---------------------------------------- > > arch/x86/kernel/setup.c | 18 ++--------------- > > 2 files changed, 3 insertions(+), 59 deletions(-) > > It would be really nice if you managed to get this rebased on current > upstream and sent out again. I'd certainly ack the x86 bits if the > Kconfig issue that 0day found was fixed up. > > Also, one nit on the cover letter: > > > There are a number of people who have expressed interest in these > > patches either by asking for them to be merge or testing them. If > > people are so inclined please continue to request them to be merge > > or to ask the status of the next release. It's helpful to motivate me to > > release them again and for the maintainers to see the interest > > generated. > > The way I'd suggest going about getting this merged is to solicit > reviews and testing from folks and then get those annotations into the > patches. As it stands, this series has zero tags in addition to the SoB > tags which I assume were its authors. How does one go about soliciting reviews from your perspective ? Typically I just submit it in this fashion and whoever is interested reviews it. Daniel
On 10/2/25 14:00, Daniel Walker (danielwa) wrote: >> The way I'd suggest going about getting this merged is to solicit >> reviews and testing from folks and then get those annotations into the >> patches. As it stands, this series has zero tags in addition to the SoB >> tags which I assume were its authors. > How does one go about soliciting reviews from your perspective ? Typically I > just submit it in this fashion and whoever is interested reviews it. First, figure out who should ideally review it. Find the maintainers, find who's been sending patches and reviewing in the area lately. Use get_maintainer.pl. Then, ask nicely. :) "Hey x86 maintainers, I've got this series with a pretty nice diffstat in arch/x86. Any chance you could take a look and give an ack if you like what you see?" You can do that in private mails, or in a separate thread, or in a reply to the original series. Or, go hunt folks down on IRC. Just tossing the series over the wall and giving it thoughts and prayers usually isn't the most effective route. BTW, your series looks like a *really* good idea. Please don't let it die. But you might want to trim it down a bit. I'd probably remove the tests and the 'insert-sys-cert' changes to make it more approachable to folks.
On Thu, Oct 02, 2025 at 02:10:13PM -0700, Dave Hansen wrote: > On 10/2/25 14:00, Daniel Walker (danielwa) wrote: > >> The way I'd suggest going about getting this merged is to solicit > >> reviews and testing from folks and then get those annotations into the > >> patches. As it stands, this series has zero tags in addition to the SoB > >> tags which I assume were its authors. > > How does one go about soliciting reviews from your perspective ? Typically I > > just submit it in this fashion and whoever is interested reviews it. > > First, figure out who should ideally review it. Find the maintainers, > find who's been sending patches and reviewing in the area lately. Use > get_maintainer.pl. > > Then, ask nicely. :) > > "Hey x86 maintainers, I've got this series with a pretty nice > diffstat in arch/x86. Any chance you could take a look and give > an ack if you like what you see?" > > You can do that in private mails, or in a separate thread, or in a reply > to the original series. Or, go hunt folks down on IRC. > > Just tossing the series over the wall and giving it thoughts and prayers > usually isn't the most effective route. I've always figured people wouldn't appreciate private emails. I guess I can try it tho. > BTW, your series looks like a *really* good idea. Please don't let it > die. But you might want to trim it down a bit. I'd probably remove the > tests and the 'insert-sys-cert' changes to make it more approachable to > folks. Since x86 is asking for it I think it would trim it down to just what is needed for x86. If I don't trim down the architectures it ropes in too many people anyway. The biggest issue is that libstub would need to be modified, but I've never had any luck getting the libstub maintainer to review anything. I suspect he would ignore private email too, particularly from people he's doesn't know. I'll try re-submitting it in the manner your suggesting. Daniel
On 10/2/25 14:31, Daniel Walker (danielwa) wrote: ... >> BTW, your series looks like a *really* good idea. Please don't let it >> die. But you might want to trim it down a bit. I'd probably remove the >> tests and the 'insert-sys-cert' changes to make it more approachable to >> folks. > > Since x86 is asking for it I think it would trim it down to just > what is needed for x86. If I don't trim down the architectures it > ropes in too many people anyway. That's not a bad idea. Or, even if you can pick two amenable architectures to start with it will make it really obvious that this is useful. Two architectures means a *lot*, IMNHO. Two is a billion times better than one. > The biggest issue is that libstub would need to be modified, but > I've never had any luck getting the libstub maintainer to review > anything. I suspect he would ignore private email too, particularly > from people he's doesn't know. Are you talking about Ard? EXTENSIBLE FIRMWARE INTERFACE (EFI) M: Ard Biesheuvel <ardb@kernel.org> L: linux-efi@vger.kernel.org S: Maintained ... F: drivers/firmware/efi/ F: include/linux/efi*.h He's a pretty nice guy and has been active in this thread, so I'm kinda surprised to hear you're having a hard time there. I'd just try asking nicely. I'm pretty sure he's "ardb" on the usual IRC networks. IRC is a great alternative when you're having problems getting your emails seen in the normal email flood. BTW, reading the changelog for libstub, it wasn't clear to me that changes there were _required_ for the series to go forward. For instance, is the x86 patch useful without libstub changes?
On Thu, Oct 02, 2025 at 02:55:07PM -0700, Dave Hansen wrote: > On 10/2/25 14:31, Daniel Walker (danielwa) wrote: > ... > >> BTW, your series looks like a *really* good idea. Please don't let it > >> die. But you might want to trim it down a bit. I'd probably remove the > >> tests and the 'insert-sys-cert' changes to make it more approachable to > >> folks. > > > > Since x86 is asking for it I think it would trim it down to just > > what is needed for x86. If I don't trim down the architectures it > > ropes in too many people anyway. > > That's not a bad idea. Or, even if you can pick two amenable > architectures to start with it will make it really obvious that this is > useful. Two architectures means a *lot*, IMNHO. Two is a billion times > better than one. ARM64 has also request this series in the past, but I don't know what their current code looks like since my last submissions. > > The biggest issue is that libstub would need to be modified, but > > I've never had any luck getting the libstub maintainer to review > > anything. I suspect he would ignore private email too, particularly > > from people he's doesn't know. > > Are you talking about Ard? > > EXTENSIBLE FIRMWARE INTERFACE (EFI) > M: Ard Biesheuvel <ardb@kernel.org> > L: linux-efi@vger.kernel.org > S: Maintained > ... > F: drivers/firmware/efi/ > F: include/linux/efi*.h Yes I think so. > He's a pretty nice guy and has been active in this thread, so I'm kinda > surprised to hear you're having a hard time there. I'd just try asking > nicely. I'm pretty sure he's "ardb" on the usual IRC networks. IRC is a > great alternative when you're having problems getting your emails seen > in the normal email flood. That was the first response from him over many submissions. Which channels are popular on IRC ? > BTW, reading the changelog for libstub, it wasn't clear to me that > changes there were _required_ for the series to go forward. For > instance, is the x86 patch useful without libstub changes? I think it is required because x86 can be compiled with libstub and the changes take effect for the whole kernel when compiled for that architecture. libstub uses the Kconfig options directly which I modify in the series, so there would need to be some compatibility changes. Daniel
On 10/2/25 16:39, Daniel Walker (danielwa) wrote: >> He's a pretty nice guy and has been active in this thread, so I'm >> kinda surprised to hear you're having a hard time there. I'd just >> try asking nicely. I'm pretty sure he's "ardb" on the usual IRC >> networks. IRC is a great alternative when you're having problems >> getting your emails seen in the normal email flood. > That was the first response from him over many submissions. Which > channels are popular on IRC ? For your purposes, just get on a network or two, look for the folks you want to talk to, and join some of the channels they are in.
On Thu, 2025-10-02 at 14:55 -0700, Dave Hansen wrote: > That's not a bad idea. Or, even if you can pick two amenable > architectures to start with it will make it really obvious that this is > useful. Two architectures means a *lot*, IMNHO. Two is a billion times > better than one. I think it's a bad idea, if I understand it correctly. The patchset conceptually patches a mechanism of the kernel as a whole, but one which just so happens to need to be implemented separately for each arch. Breaking it down like you suggest creates an embarrassingly high likelihood of different architectures' implementations of it going out of sync, a previous situation that this patchset was partly intended to address. I say keep it atomic. If it breaks on an arch or two but not others and nobody notices right away, that would be better addressed with a new patch when someone eventually does notice. Just my 2¢…
On 10/2/25 15:38, Daniel Gimpelevich wrote: > On Thu, 2025-10-02 at 14:55 -0700, Dave Hansen wrote: >> That's not a bad idea. Or, even if you can pick two amenable >> architectures to start with it will make it really obvious that this is >> useful. Two architectures means a *lot*, IMNHO. Two is a billion times >> better than one. > I think it's a bad idea, if I understand it correctly. The patchset > conceptually patches a mechanism of the kernel as a whole, but one which > just so happens to need to be implemented separately for each arch. > Breaking it down like you suggest creates an embarrassingly high > likelihood of different architectures' implementations of it going out > of sync, a previous situation that this patchset was partly intended to > address. I say keep it atomic. If it breaks on an arch or two but not > others and nobody notices right away, that would be better addressed > with a new patch when someone eventually does notice. Just my 2¢… How is the approach to "keep it atomic" working out so far? ;) The kernel isn't exactly developed in secret. It's also not hard at all to, say, once a week to peek at linux-next and do a lore search (or use lei) if anyone is desperately worried about the ~50 lines per architecture going out of sync.
On Thu, 2025-10-02 at 16:10 -0700, Dave Hansen wrote: > How is the approach to "keep it atomic" working out so far? ;) > > The kernel isn't exactly developed in secret. It's also not hard at all > to, say, once a week to peek at linux-next and do a lore search (or use > lei) if anyone is desperately worried about the ~50 lines per > architecture going out of sync. With all due respect, the lack of action on this patchset is not at all due to its scope, but purely due to the throwing-spaghetti-at-the-wall approach to code review that you yourself just got done pointing out. Addressing the latter problem would thereby also address the former.
Hi Daniel,
kernel test robot noticed the following build warnings:
[auto build test WARNING on v6.6]
[cannot apply to arm64/for-next/core efi/next tip/x86/core robh/for-next linus/master next-20231110]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Daniel-Walker/CMDLINE-add-generic-builtin-command-line/20231110-094423
base: v6.6
patch link: https://lore.kernel.org/r/20231110013817.2378507-7-danielwa%40cisco.com
patch subject: [PATCH 6/8] CMDLINE: x86: convert to generic builtin command line
config: x86_64-kismet-CONFIG_SYSTEM_EXTRA_CERTIFICATE-CONFIG_CMDLINE_EXTRA-0-0 (https://download.01.org/0day-ci/archive/20231110/202311101507.q12gPUvS-lkp@intel.com/config)
reproduce: (https://download.01.org/0day-ci/archive/20231110/202311101507.q12gPUvS-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202311101507.q12gPUvS-lkp@intel.com/
kismet warnings: (new ones prefixed by >>)
>> kismet: WARNING: unmet direct dependencies detected for SYSTEM_EXTRA_CERTIFICATE when selected by CMDLINE_EXTRA
WARNING: unmet direct dependencies detected for SYSTEM_EXTRA_CERTIFICATE
Depends on [n]: CRYPTO [=y] && SYSTEM_TRUSTED_KEYRING [=n]
Selected by [y]:
- CMDLINE_EXTRA [=y] && GENERIC_CMDLINE [=y] && CMDLINE_BOOL [=y]
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
© 2016 - 2025 Red Hat, Inc.