[1/4] add generic builtin command line
diff mbox series

Message ID 20190319232448.45964-2-danielwa@cisco.com
State New, archived
Headers show
Series
  • [1/4] add generic builtin command line
Related show

Commit Message

Daniel Walker March 19, 2019, 11:24 p.m. UTC
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.

[maksym.kokhan@globallogic.com: fix cmdline_add_builtin() macro]
Cc: Daniel Walker <dwalker@fifo99.com>
Cc: Daniel Walker <danielwa@cisco.com>
Cc: xe-linux-external@cisco.com
Signed-off-by: Daniel Walker <danielwa@cisco.com>
Signed-off-by: Maksym Kokhan <maksym.kokhan@globallogic.com>
---
 include/linux/cmdline.h | 69 +++++++++++++++++++++++++++++++++++++++++
 init/Kconfig            | 69 +++++++++++++++++++++++++++++++++++++++++
 2 files changed, 138 insertions(+)
 create mode 100644 include/linux/cmdline.h

Comments

Andrew Morton March 20, 2019, 10:53 p.m. UTC | #1
On Tue, 19 Mar 2019 16:24:45 -0700 Daniel Walker <danielwa@cisco.com> 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.
Daniel Walker March 20, 2019, 11:23 p.m. UTC | #2
On Wed, Mar 20, 2019 at 03:53:19PM -0700, Andrew Morton wrote:
> On Tue, 19 Mar 2019 16:24:45 -0700 Daniel Walker <danielwa@cisco.com> 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 <danielwa@cisco.com>
 36 To: Andrew Morton <akpm@linux-foundation.org>,
 37         Christophe Leroy <christophe.leroy@c-s.fr>,
 38         Michael Ellerman <mpe@ellerman.id.au>,
 39         Rob Herring <robh+dt@kernel.org>, xe-linux-external@cisco.com,
 40         linuxppc-dev@lists.ozlabs.org, Frank Rowand <frowand.list@gmail.com>
 41 Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
 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
Andrew Morton March 21, 2019, 3:14 a.m. UTC | #3
On Wed, 20 Mar 2019 16:23:28 -0700 Daniel Walker <danielwa@cisco.com> 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 <danielwa@cisco.com> 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 <danielwa@cisco.com>
>  36 To: Andrew Morton <akpm@linux-foundation.org>,
>  37         Christophe Leroy <christophe.leroy@c-s.fr>,
>  38         Michael Ellerman <mpe@ellerman.id.au>,
>  39         Rob Herring <robh+dt@kernel.org>, xe-linux-external@cisco.com,
>  40         linuxppc-dev@lists.ozlabs.org, Frank Rowand <frowand.list@gmail.com>
>  41 Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
>  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.
Daniel Walker March 21, 2019, 3:13 p.m. UTC | #4
On Wed, Mar 20, 2019 at 08:14:33PM -0700, Andrew Morton wrote:
> On Wed, 20 Mar 2019 16:23:28 -0700 Daniel Walker <danielwa@cisco.com> 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 <danielwa@cisco.com> 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 <danielwa@cisco.com>
> >  36 To: Andrew Morton <akpm@linux-foundation.org>,
> >  37         Christophe Leroy <christophe.leroy@c-s.fr>,
> >  38         Michael Ellerman <mpe@ellerman.id.au>,
> >  39         Rob Herring <robh+dt@kernel.org>, xe-linux-external@cisco.com,
> >  40         linuxppc-dev@lists.ozlabs.org, Frank Rowand <frowand.list@gmail.com>
> >  41 Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
> >  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
Andrew Morton March 21, 2019, 10:15 p.m. UTC | #5
On Thu, 21 Mar 2019 08:13:08 -0700 Daniel Walker <danielwa@cisco.com> 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.
Daniel Gimpelevich Feb. 15, 2021, 7:32 p.m. UTC | #6
On Thu, 2019-03-21 at 15:15 -0700, Andrew Morton wrote:
> On Thu, 21 Mar 2019 08:13:08 -0700 Daniel Walker <danielwa@cisco.com> 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.
Christophe Leroy Feb. 16, 2021, 5:42 p.m. UTC | #7
Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us> 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 <danielwa@cisco.com> 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/cover.1554195798.git.christophe.leroy@c-s.fr/ 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
Daniel Walker Feb. 16, 2021, 7:02 p.m. UTC | #8
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 <danielwa@cisco.com> 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
Daniel Gimpelevich Feb. 16, 2021, 9:20 p.m. UTC | #9
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.
Andrew Morton Feb. 17, 2021, 9:16 p.m. UTC | #10
On Mon, 15 Feb 2021 11:32:01 -0800 Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us> wrote:

> On Thu, 2019-03-21 at 15:15 -0700, Andrew Morton wrote:
> > On Thu, 21 Mar 2019 08:13:08 -0700 Daniel Walker <danielwa@cisco.com> 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,

Patch
diff mbox series

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"