This code allows architectures to use a generic builtin command line.
The state of the builtin command line options across architecture is
diverse. On x86 and mips they have pretty much the same code and the
code prepends the builtin command line onto the boot loader provided
one. On powerpc there is only a builtin override and nothing else.
The code in this commit unifies the mips and x86 code into a generic
header file under the CONFIG_GENERIC_CMDLINE option. When this
option is enabled the architecture can call the cmdline_add_builtin()
to add the builtin command line.
[[email protected]: fix cmdline_add_builtin() macro]
Cc: Daniel Walker <[email protected]>
Cc: Daniel Walker <[email protected]>
Cc: [email protected]
Signed-off-by: Daniel Walker <[email protected]>
Signed-off-by: Maksym Kokhan <[email protected]>
---
include/linux/cmdline.h | 69 +++++++++++++++++++++++++++++++++++++++++
init/Kconfig | 69 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 138 insertions(+)
create mode 100644 include/linux/cmdline.h
diff --git a/include/linux/cmdline.h b/include/linux/cmdline.h
new file mode 100644
index 000000000000..4a16ee134585
--- /dev/null
+++ b/include/linux/cmdline.h
@@ -0,0 +1,69 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_CMDLINE_H
+#define _LINUX_CMDLINE_H
+
+/*
+ *
+ * Copyright (C) 2015. Cisco Systems, Inc.
+ *
+ * Generic Append/Prepend cmdline support.
+ */
+
+#if defined(CONFIG_GENERIC_CMDLINE) && defined(CONFIG_CMDLINE_BOOL)
+
+#ifndef CONFIG_CMDLINE_OVERRIDE
+/*
+ * This function will append or prepend a builtin command line to the command
+ * line provided by the bootloader. Kconfig options can be used to alter
+ * the behavior of this builtin command line.
+ * @dest: The destination of the final appended/prepended string
+ * @src: The starting string or NULL if there isn't one.
+ * @tmp: temporary space used for prepending
+ * @length: the maximum length of the strings above.
+ */
+static inline void
+_cmdline_add_builtin(char *dest, char *src, char *tmp, unsigned long length)
+{
+ if (src != dest && src != NULL) {
+ strlcpy(dest, " ", length);
+ strlcat(dest, src, length);
+ }
+
+ if (sizeof(CONFIG_CMDLINE_APPEND) > 1)
+ strlcat(dest, " " CONFIG_CMDLINE_APPEND, length);
+
+ if (sizeof(CONFIG_CMDLINE_PREPEND) > 1) {
+ strlcpy(tmp, CONFIG_CMDLINE_PREPEND " ", length);
+ strlcat(tmp, dest, length);
+ strlcpy(dest, tmp, length);
+ }
+}
+
+#define cmdline_add_builtin_section(dest, src, length, section) \
+{ \
+ if (sizeof(CONFIG_CMDLINE_PREPEND) > 1) { \
+ static char cmdline_tmp_space[length] section; \
+ _cmdline_add_builtin(dest, src, cmdline_tmp_space, length); \
+ } else { \
+ _cmdline_add_builtin(dest, src, NULL, length); \
+ } \
+}
+#else
+#define cmdline_add_builtin_section(dest, src, length, section) \
+{ \
+ strlcpy(dest, CONFIG_CMDLINE_PREPEND " " CONFIG_CMDLINE_APPEND, \
+ length); \
+}
+#endif /* !CONFIG_CMDLINE_OVERRIDE */
+
+#else
+#define cmdline_add_builtin_section(dest, src, length, section) { \
+ if (src != NULL) \
+ strlcpy(dest, src, length); \
+}
+#endif /* CONFIG_GENERIC_CMDLINE */
+
+#define cmdline_add_builtin(dest, src, length) \
+ cmdline_add_builtin_section(dest, src, length, __initdata)
+
+#endif /* _LINUX_CMDLINE_H */
diff --git a/init/Kconfig b/init/Kconfig
index d47cb77a220e..b9b9e7702ea3 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1778,6 +1778,75 @@ config PROFILING
config TRACEPOINTS
bool
+config GENERIC_CMDLINE
+ bool
+
+if GENERIC_CMDLINE
+
+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
+ 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_APPEND
+ string "Built-in kernel command string append"
+ 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, this string is appended to it 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_PREPEND
+ string "Built-in kernel command string prepend"
+ 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, this string is prepended to it 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
+ help
+ Set this option to 'Y' to have the kernel ignore the boot loader
+ command line, and use ONLY the built-in command line. In this case
+ append and prepend strings are concatenated to form the full
+ command line.
+
+ This is used to work around broken boot loaders. This should
+ be set to 'N' under normal conditions.
+
+endif
+
endmenu # General setup
source "arch/Kconfig"
--
2.19.1
On Tue, 19 Mar 2019 16:24:45 -0700 Daniel Walker <[email protected]> wrote:
> This code allows architectures to use a generic builtin command line.
I wasn't cc'ed on [2/4]. No mailing lists were cc'ed on [0/4] but it
didn't say anything useful anyway ;)
I'll queue them up for testing and shall await feedback from the
powerpc developers.
On Wed, Mar 20, 2019 at 03:53:19PM -0700, Andrew Morton wrote:
> On Tue, 19 Mar 2019 16:24:45 -0700 Daniel Walker <[email protected]> wrote:
>
> > This code allows architectures to use a generic builtin command line.
>
> I wasn't cc'ed on [2/4]. No mailing lists were cc'ed on [0/4] but it
> didn't say anything useful anyway ;)
>
> I'll queue them up for testing and shall await feedback from the
> powerpc developers.
>
You weren't CC'd , but it was To: you,
35 From: Daniel Walker <[email protected]>
36 To: Andrew Morton <[email protected]>,
37 Christophe Leroy <[email protected]>,
38 Michael Ellerman <[email protected]>,
39 Rob Herring <[email protected]>, [email protected],
40 [email protected], Frank Rowand <[email protected]>
41 Cc: [email protected], [email protected]
42 Subject: [PATCH 2/4] drivers: of: generic command line support
and the first one [0/4] should have went to the linuxppc-dev , and xe-linux-external. Maybe
our git-send-email isn't working with our mail servers.
Thanks for picking it up.
Daniel
On Wed, 20 Mar 2019 16:23:28 -0700 Daniel Walker <[email protected]> wrote:
> On Wed, Mar 20, 2019 at 03:53:19PM -0700, Andrew Morton wrote:
> > On Tue, 19 Mar 2019 16:24:45 -0700 Daniel Walker <[email protected]> wrote:
> >
> > > This code allows architectures to use a generic builtin command line.
> >
> > I wasn't cc'ed on [2/4]. No mailing lists were cc'ed on [0/4] but it
> > didn't say anything useful anyway ;)
> >
> > I'll queue them up for testing and shall await feedback from the
> > powerpc developers.
> >
>
> You weren't CC'd , but it was To: you,
>
> 35 From: Daniel Walker <[email protected]>
> 36 To: Andrew Morton <[email protected]>,
> 37 Christophe Leroy <[email protected]>,
> 38 Michael Ellerman <[email protected]>,
> 39 Rob Herring <[email protected]>, [email protected],
> 40 [email protected], Frank Rowand <[email protected]>
> 41 Cc: [email protected], [email protected]
> 42 Subject: [PATCH 2/4] drivers: of: generic command line support
hm.
> Thanks for picking it up.
The patches (or some version of them) are already in linux-next,
which messes me up. I'll disable them for now.
On Wed, Mar 20, 2019 at 08:14:33PM -0700, Andrew Morton wrote:
> On Wed, 20 Mar 2019 16:23:28 -0700 Daniel Walker <[email protected]> wrote:
>
> > On Wed, Mar 20, 2019 at 03:53:19PM -0700, Andrew Morton wrote:
> > > On Tue, 19 Mar 2019 16:24:45 -0700 Daniel Walker <[email protected]> wrote:
> > >
> > > > This code allows architectures to use a generic builtin command line.
> > >
> > > I wasn't cc'ed on [2/4]. No mailing lists were cc'ed on [0/4] but it
> > > didn't say anything useful anyway ;)
> > >
> > > I'll queue them up for testing and shall await feedback from the
> > > powerpc developers.
> > >
> >
> > You weren't CC'd , but it was To: you,
> >
> > 35 From: Daniel Walker <[email protected]>
> > 36 To: Andrew Morton <[email protected]>,
> > 37 Christophe Leroy <[email protected]>,
> > 38 Michael Ellerman <[email protected]>,
> > 39 Rob Herring <[email protected]>, [email protected],
> > 40 [email protected], Frank Rowand <[email protected]>
> > 41 Cc: [email protected], [email protected]
> > 42 Subject: [PATCH 2/4] drivers: of: generic command line support
>
> hm.
>
> > Thanks for picking it up.
>
> The patches (or some version of them) are already in linux-next,
> which messes me up. I'll disable them for now.
Those are from my tree, but I remove them when you picked up the series. The
next linux-next should not have them.
Daniel
On Thu, 21 Mar 2019 08:13:08 -0700 Daniel Walker <[email protected]> wrote:
> > The patches (or some version of them) are already in linux-next,
> > which messes me up. I'll disable them for now.
>
> Those are from my tree, but I remove them when you picked up the series. The
> next linux-next should not have them.
Yup, thanks, all looks good now.
On Thu, 2019-03-21 at 15:15 -0700, Andrew Morton wrote:
> On Thu, 21 Mar 2019 08:13:08 -0700 Daniel Walker <[email protected]> wrote:
> > On Wed, Mar 20, 2019 at 08:14:33PM -0700, Andrew Morton wrote:
> > > The patches (or some version of them) are already in linux-next,
> > > which messes me up. I'll disable them for now.
> >
> > Those are from my tree, but I remove them when you picked up the series. The
> > next linux-next should not have them.
>
> Yup, thanks, all looks good now.
This patchset is currently neither in mainline nor in -next. May I ask
what happened to it? Thanks.
Daniel Gimpelevich <[email protected]> a écrit :
> On Thu, 2019-03-21 at 15:15 -0700, Andrew Morton wrote:
>> On Thu, 21 Mar 2019 08:13:08 -0700 Daniel Walker <[email protected]> wrote:
>> > On Wed, Mar 20, 2019 at 08:14:33PM -0700, Andrew Morton wrote:
>> > > The patches (or some version of them) are already in linux-next,
>> > > which messes me up. I'll disable them for now.
>> >
>> > Those are from my tree, but I remove them when you picked up the
>> series. The
>> > next linux-next should not have them.
>>
>> Yup, thanks, all looks good now.
>
> This patchset is currently neither in mainline nor in -next. May I ask
> what happened to it? Thanks.
As far as I remember, there has been a lot of discussion around this series.
As of today, it doesn't apply cleanly anymore and would require rebasing.
I'd suggest also to find the good arguments to convince us that this
series has a real added value, not just "cisco use it in its kernels
so it is good".
I proposed an alternative at
https://patchwork.ozlabs.org/project/linuxppc-dev/cover/[email protected]/ but never got any feedback so I gave
up.
If you submit a new series, don't forget to copy ppclinux-dev and
linux-arch lists.
Christophe
On Mon, Feb 15, 2021 at 11:32:01AM -0800, Daniel Gimpelevich wrote:
> On Thu, 2019-03-21 at 15:15 -0700, Andrew Morton wrote:
> > On Thu, 21 Mar 2019 08:13:08 -0700 Daniel Walker <[email protected]> wrote:
> > > On Wed, Mar 20, 2019 at 08:14:33PM -0700, Andrew Morton wrote:
> > > > The patches (or some version of them) are already in linux-next,
> > > > which messes me up. I'll disable them for now.
> > >
> > > Those are from my tree, but I remove them when you picked up the series. The
> > > next linux-next should not have them.
> >
> > Yup, thanks, all looks good now.
>
> This patchset is currently neither in mainline nor in -next. May I ask
> what happened to it? Thanks.
>
It was dropped silently by Andrew at some point. I wasn't watching -next closely
to know when. I have no idea why he dropped it.
We still use this series extensively in Cisco, and have extended it beyond this
current series.
We can re-submit.
Daniel
On Tue, 2021-02-16 at 18:42 +0100, Christophe Leroy wrote:
> I'd suggest also to find the good arguments to convince us that this
> series has a real added value, not just "cisco use it in its kernels
> so it is good".
Well, IIRC, this series was endorsed by the device tree maintainers as
the preferred alternative to this:
https://lore.kernel.org/linux-devicetree/1565020400-25679-1-git-send-email-daniel@gimpelevich.san-francisco.ca.us/T/#u
The now-defunct patchwork.linux-mips.org link in that thread pointed to:
https://lore.kernel.org/linux-mips/1510796793.16864.25.camel@chimera/T/#u
When running modern kernels from ancient vendor bootloaders, it is
sometimes necessary to pick and choose bits and pieces of the info they
pass without taking it verbatim.
On Mon, 15 Feb 2021 11:32:01 -0800 Daniel Gimpelevich <[email protected]> wrote:
> On Thu, 2019-03-21 at 15:15 -0700, Andrew Morton wrote:
> > On Thu, 21 Mar 2019 08:13:08 -0700 Daniel Walker <[email protected]> wrote:
> > > On Wed, Mar 20, 2019 at 08:14:33PM -0700, Andrew Morton wrote:
> > > > The patches (or some version of them) are already in linux-next,
> > > > which messes me up. I'll disable them for now.
> > >
> > > Those are from my tree, but I remove them when you picked up the series. The
> > > next linux-next should not have them.
> >
> > Yup, thanks, all looks good now.
>
> This patchset is currently neither in mainline nor in -next. May I ask
> what happened to it? Thanks.
Seems that I didn't bring them back after the confict with the powerpc
tree resolved itself.
Please resend everything for -rc1 and let's await the reviewer
feedback,
This seems quite useful. Can you please merge it?
On Mon, Apr 17, 2023 at 06:18:18PM +0200, Tomas Mudrunka wrote:
> This seems quite useful. Can you please merge it?
I need to re-send it before it can be merge. I'll try to update it soon.
Daniel
Hi Daniel
We have a usecase which requires this patch necessarily. For android
usecases, we have two different build variants
differentiated by defconfigs - production and debug. However, we only
have a single dts for both these variants.
We want to enable certain features like page owner and slub debug which
require cmdline params in addition to
their respective configs to be enabled. Enabling page_owner and
slub_debug options in dts file enables it for both
production and debug variants. These features have significant memory
overhead which are undesirable for
our production environment. However, these are necessary for debug
environment to enable internal testing and debug.
Currently, android uses out-of-tree configs like CONFIG_CMDLINE_EXTEND
to do so in gki_defconfig [1].
One option is to use CMDLINE_FORCE option which would enable these
cmdline params but this disables the bootloader to add
any additional cmdline params which may be necessary.
For such a usecase, the CONFIG_CMDLINE_PREPEND seems to be quite useful
as it would help to stitch bootloader
and the desired build variant's configs together. Can you please help to
merge this patch?
[1]
https://android.googlesource.com/kernel/common/+/refs/heads/android14-6.1-lts/arch/arm64/configs/gki_defconfig#62
On Tue, Oct 17, 2023 at 04:10:42PM +0530, Pratyush Brahma wrote:
> For such a usecase, the CONFIG_CMDLINE_PREPEND seems to be quite useful as
> it would help to stitch bootloader
> and the desired build variant's configs together. Can you please help to
> merge this patch?
Yes, your at least the second person that's asked for it, and it's been on my
list for some time to release again. I'll try to release it as soon as possible.
Daniel
On 17-10-2023 19:51, Daniel Walker (danielwa) wrote:
> On Tue, Oct 17, 2023 at 04:10:42PM +0530, Pratyush Brahma wrote:
>> For such a usecase, the CONFIG_CMDLINE_PREPEND seems to be quite useful as
>> it would help to stitch bootloader
>> and the desired build variant's configs together. Can you please help to
>> merge this patch?
> Yes, your at least the second person that's asked for it, and it's been on my
> list for some time to release again. I'll try to release it as soon as possible.
>
> Daniel
Thanks Daniel.
Please have this config support for arm64 as well. Previously arm64 used
to support CONFIG_CMDLINE_EXTEND
which was useful for our usecase. However it was dropped from commit
cae118b6acc309539b33339e846cbb19187c164c
referring to your patch series as an alternative. Hence the need.
Pratyush