All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel Walker (danielwa)" <danielwa@cisco.com>
To: Brian Mak <makb@juniper.net>
Cc: Dave Hansen <dave.hansen@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RESEND] x86/boot: Add option to append to the cmdline
Date: Thu, 2 Oct 2025 20:33:46 +0000	[thread overview]
Message-ID: <aN7hqiQg1cDIMIG9@goliath> (raw)
In-Reply-To: <D435A8B5-46E2-440C-940F-A3FE5364C1CD@juniper.net>

On Thu, Oct 02, 2025 at 05:30:10PM +0000, Brian Mak wrote:
> On Oct 1, 2025, at 5:13 PM, Dave Hansen <dave.hansen@intel.com> wrote:
> 
> > On 10/1/25 16:04, Brian Mak wrote:
> >> To solve this limitation, we add CONFIG_CMDLINE_EXTEND, which is already
> >> available on several other architectures, to make the built-in command
> >> line append to the bootloader-provided command line.
> > 
> > I'd really rather not have another copy-and-paste of another
> > architecture's Kconfig bits into x86.
> > 
> > At the _very_ least, we'd get a boolean ARCH_HAS_CMDLIND_EXTEND which
> > would then expose an arch-independent CMDLINE_EXTEND option. Literally
> > duplicating Kconfig options just isn't scalable.
> 
> Hi Dave,
> 
> Thanks for your comments!
> 
> Sure, I'll introduce an arch-independent (ARCH_HAS_)CMDLINE_EXTEND option
> in v2.
> 
> > I also cringe every time I see code like this get added to arch/x86 that
> > really doesn't have anything to do with x86 and really only gets dumped
> > in to arch/ because there's never been a proper refactoring of all the
> > copy-and-pasted code.
> > 
> > In the end, refactoring Kconfig is dirt simple. Refactoring
> > builtin_cmdline[] into arch-independent code would be a lot harder.
> 
> In the past, there have been efforts to add arch-independent cmdline
> processing [1] (CC: Daniel Walker). These efforts have been stalled for a
> long time now though.


We use my change at Cisco in production, but I don't submit it often enough.

Daniel

  reply	other threads:[~2025-10-02 20:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-01 23:04 [PATCH RESEND] x86/boot: Add option to append to the cmdline Brian Mak
2025-10-02  0:13 ` Dave Hansen
2025-10-02 17:30   ` Brian Mak
2025-10-02 20:33     ` Daniel Walker (danielwa) [this message]
  -- strict thread matches above, loose matches on Subject: below --
2025-09-15 20:26 Brian Mak

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=aN7hqiQg1cDIMIG9@goliath \
    --to=danielwa@cisco.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=makb@juniper.net \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.