linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Tyler Hicks <tyhicks@linux.microsoft.com>
To: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Rob Herring <robh+dt@kernel.org>,
	Pavel Tatashin <pasha.tatashin@soleen.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] arm64: Implement CONFIG_CMDLINE_EXTEND
Date: Wed, 4 Nov 2020 23:40:09 -0600	[thread overview]
Message-ID: <20201105054009.GA4472@sequoia> (raw)
In-Reply-To: <20201104120812.GA6632@willie-the-truck>

On 2020-11-04 12:08:12, Will Deacon wrote:
> On Tue, Nov 03, 2020 at 09:59:52AM -0600, Tyler Hicks wrote:
> > On 2020-09-21 14:15:55, Tyler Hicks wrote:
> > > Provide the CONFIG_CMDLINE_EXTEND config option for arm64 kernels. This
> > > config option can be used to extend the kernel command line parameters,
> > > specified by the bootloader, with additional command line parameters
> > > specified in the kernel configuration.
> > 
> > Hi Catalin and Will - Friendly ping on this series now that we're
> > on the other side of the 5.10 merge window. I hope it can be considered
> > for 5.10+1. Let me know if I need to rebase/resubmit. Thanks!
> 
> Can you use bootconfig to achieve what you need?

Thanks for mentioning bootconfig. I hadn't considered it.

After reading the docs and code, I see a few reasons why I can't use it
out of the box:

 1) It requires "bootconfig" to be appended to the kernel command line.
    My proposed patch series makes it possible to append new options to
    the kernel command line in situations where the bootloader is not
    interactive. This presents a circular dependency problem for my use
    case.

    A new config option could be added to force the enablement of
    bootconfig but that would sort of be a single-use duplicate of
    CONFIG_CMDLINE_EXTEND's functionality.

 2) Not all kernel command line options can be configured using
    bootconfig. For example, the "nokaslr" and "crashkernel=" parameters
    are parsed/handled before setup_boot_config() is called. KASLR can
    be disabled via a kernel config change but there's no config option
    equivalent for "crashkernel=". Changing the "crashkernel=" command
    line option is something that I need to support because a
    development/debug kernel build often requires a larger reservation
    and we find ourselves adjusting the "crashkernel=" value fairly
    often.

 3) External FIT image build systems do not yet support bootconfig since
    it is so new. It is completely fair if you file this away in your
    not-my-problem folder but simple kernel config modifications, as
    needed for CONFIG_CMDLINE_EXTEND, are something that every image
    build system is likely to support today.

All that said, I do really like the look of bootconfig. Unfortunately,
it doesn't let me achieve everything I need.

Tyler

> 
> Will
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-11-05  5:40 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-21 19:15 [PATCH 0/2] arm64: Implement CONFIG_CMDLINE_EXTEND Tyler Hicks
2020-09-21 19:15 ` [PATCH 1/2] arm64: kaslr: Refactor early init command line parsing Tyler Hicks
2020-09-21 19:15 ` [PATCH 2/2] arm64: Extend the kernel command line from the bootloader Tyler Hicks
2020-11-03 15:59 ` [PATCH 0/2] arm64: Implement CONFIG_CMDLINE_EXTEND Tyler Hicks
2020-11-04 12:08   ` Will Deacon
2020-11-05  5:40     ` Tyler Hicks [this message]
2020-11-05  9:58       ` Will Deacon
2020-11-05 15:28         ` Tyler Hicks
2020-11-19 16:56           ` Tyler Hicks
2020-11-19 19:25             ` Will Deacon
2020-11-20 13:50           ` Rob Herring
2020-11-27 19:12 ` Catalin Marinas

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=20201105054009.GA4472@sequoia \
    --to=tyhicks@linux.microsoft.com \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pasha.tatashin@soleen.com \
    --cc=robh+dt@kernel.org \
    --cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).