From: Ian Campbell <ijc@debian.org>
To: Will Deacon <will.deacon@arm.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: mark.rutland@arm.com, linux-efi@vger.kernel.org,
Geoff Levand <geoff@infradead.org>,
catalin.marinas@arm.com, Riku Voipio <riku.voipio@linaro.org>,
Sudeep Holla <sudeep.holla@arm.com>,
leif.lindholm@linaro.org, linux-acpi@vger.kernel.org,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
James Morse <james.morse@arm.com>,
Hanjun Guo <hanjun.guo@linaro.org>,
Mark Salter <msalter@redhat.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 0/2] efi: add contents of LinuxExtraArgs EFI var to command line
Date: Thu, 12 Jul 2018 20:24:19 +0100 [thread overview]
Message-ID: <1531423459.3582.15.camel@debian.org> (raw)
In-Reply-To: <20180712170134.GF26935@arm.com>
On Thu, 2018-07-12 at 18:01 +0100, Will Deacon wrote:
On Wed, Jul 04, 2018 at 05:49:17PM +0200, Ard Biesheuvel wrote:
> > Especially for UEFI systems, if upgrading
> > firmware is a reasonable prerequisite for being able to upgrade to the latest
Is it?
There's zero chance that there will be new firmware for the system in
question, but even if there were I'm not sure it should be considered a
n at all reasonable thing to ask in the general case (I know that if
x86 jumped off a cliff ARM wouldn't follow, but it certainly isn't
considered reasonable in the common case in that world).
> I'm torn on this one. Whilst I strongly agree that keying off DMI tables
> to detect firmware quirks is a bad idea on arm64, silently extending the
> kernel command-line also has its downsides. The command-line provides ways
> to override kernel defaults, so if a user has forced a feature on/off,
> then I think this should take precedence over quirks and we should taint
> instead, rather than silently override the option.
>
> I'd be interested in other opinions on this.
FWIW it seems to me that if we aren't going to have these systems Just
work with newer kernels and instead require users to perform some sort
of reconfiguration (which seems like a great shame to me, but I'll let
that horse lie[0]) then it seems like they can just as easily add this
command line parameter via existing mechanisms (/etc/default/grub etc)
without needing to invent some new way of doing so (one which is more
obscure and perhaps harder to configure).
Likewise distros, they can chose to either require their users to make
those changes (see above), or they can choose not to support those
systems any more or to not enable the config options which expose the
issue.
Ian.
[0] OK, I will just mention that I don't believe it needs to be a DMI
quirk -- if there were some other way to detect and make things just
work then that would be great too. Now I'm done with the horse.
WARNING: multiple messages have this Message-ID (diff)
From: ijc@debian.org (Ian Campbell)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 0/2] efi: add contents of LinuxExtraArgs EFI var to command line
Date: Thu, 12 Jul 2018 20:24:19 +0100 [thread overview]
Message-ID: <1531423459.3582.15.camel@debian.org> (raw)
In-Reply-To: <20180712170134.GF26935@arm.com>
On Thu, 2018-07-12 at 18:01 +0100, Will Deacon wrote:
On Wed, Jul 04, 2018 at 05:49:17PM +0200, Ard Biesheuvel wrote:
> > Especially for UEFI systems, if upgrading
> > firmware is a reasonable prerequisite for being able to upgrade to the latest
Is it?
There's zero chance that there will be new firmware for the system in
question, but even if there were I'm not sure it should be considered a
n at all reasonable thing to ask in the general case (I know that if
x86 jumped off a cliff ARM wouldn't follow, but it certainly isn't
considered reasonable in the common case in that world).
> I'm torn on this one. Whilst I strongly agree that keying off DMI tables
> to detect firmware quirks is a bad idea on arm64, silently extending the
> kernel command-line also has its downsides. The command-line provides ways
> to override kernel defaults, so if a user has forced a feature on/off,
> then I think this should take precedence over quirks and we should taint
> instead, rather than silently override the option.
>
> I'd be interested in other opinions on this.
FWIW it seems to me that if we aren't going to have these systems Just
work with newer kernels and instead require users to perform some sort
of reconfiguration (which seems like a great shame to me, but I'll let
that horse lie[0]) then it seems like they can just as easily add this
command line parameter via existing mechanisms (/etc/default/grub etc)
without needing to invent some new way of doing so (one which is more
obscure and perhaps harder to configure).
Likewise distros, they can chose to either require their users to make
those changes (see above), or they can choose not to support those
systems any more or to not enable the config options which expose the
issue.
Ian.
[0] OK, I will just mention that I don't believe it needs to be a DMI
quirk -- if there were some other way to detect and make things just
work then that would be great too. Now I'm done with the horse.
next prev parent reply other threads:[~2018-07-12 19:24 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-04 15:49 [RFC PATCH 0/2] efi: add contents of LinuxExtraArgs EFI var to command line Ard Biesheuvel
2018-07-04 15:49 ` Ard Biesheuvel
2018-07-04 15:49 ` [RFC PATCH 1/2] efi/libstub: refactor load option command line processing for reuse Ard Biesheuvel
2018-07-04 15:49 ` Ard Biesheuvel
2018-07-04 15:49 ` [RFC PATCH 2/2] efi/libstub: taken contents of LinuxExtraArgs UEFI variable into account Ard Biesheuvel
2018-07-04 15:49 ` Ard Biesheuvel
2018-07-12 17:01 ` [RFC PATCH 0/2] efi: add contents of LinuxExtraArgs EFI var to command line Will Deacon
2018-07-12 17:01 ` Will Deacon
2018-07-12 17:39 ` Ard Biesheuvel
2018-07-12 17:39 ` Ard Biesheuvel
2018-07-12 19:24 ` Ian Campbell [this message]
2018-07-12 19:24 ` Ian Campbell
2018-07-12 22:22 ` Geoff Levand
2018-07-12 22:22 ` Geoff Levand
2018-07-13 6:15 ` Ard Biesheuvel
2018-07-13 6:15 ` Ard Biesheuvel
2018-07-13 9:56 ` Will Deacon
2018-07-13 9:56 ` Will Deacon
2018-07-13 15:59 ` Geoff Levand
2018-07-13 15:59 ` Geoff Levand
2018-07-31 15:54 ` Geoff Levand
2018-07-31 15:54 ` Geoff Levand
2018-08-01 10:07 ` James Morse
2018-08-01 10:07 ` James Morse
2018-08-02 15:47 ` Graeme Gregory
2018-08-02 15:47 ` Graeme Gregory
2018-08-06 21:23 ` Geoff Levand
2018-08-06 21:23 ` Geoff Levand
2018-07-13 10:02 ` Ian Campbell
2018-07-13 10:02 ` Ian Campbell
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=1531423459.3582.15.camel@debian.org \
--to=ijc@debian.org \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=geoff@infradead.org \
--cc=hanjun.guo@linaro.org \
--cc=james.morse@arm.com \
--cc=leif.lindholm@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=msalter@redhat.com \
--cc=riku.voipio@linaro.org \
--cc=sudeep.holla@arm.com \
--cc=will.deacon@arm.com \
/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.