U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: U-Boot Mailing List <u-boot@lists.denx.de>,
	Alexander Graf <agraf@csgraf.de>,
	Masahisa Kojima <masahisa.kojima@linaro.org>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	AKASHI Takahiro <takahiro.akashi@linaro.org>,
	Simon Glass <sjg@chromium.org>
Subject: Re: Pull request for efi-2021-10-rc4
Date: Sat, 4 Sep 2021 14:08:25 -0400	[thread overview]
Message-ID: <20210904180825.GJ12964@bill-the-cat> (raw)
In-Reply-To: <8FD4F99B-E1A5-4842-8BB8-EA2749E4761B@gmx.de>

[-- Attachment #1: Type: text/plain, Size: 5183 bytes --]

On Sat, Sep 04, 2021 at 08:02:49PM +0200, Heinrich Schuchardt wrote:
> 
> 
> Am 4. September 2021 19:39:49 MESZ schrieb Tom Rini <trini@konsulko.com>:
> >On Sat, Sep 04, 2021 at 07:03:48PM +0200, Heinrich Schuchardt wrote:
> >> 
> >> 
> >> Am 4. September 2021 16:37:22 MESZ schrieb Tom Rini <trini@konsulko.com>:
> >> >On Sat, Sep 04, 2021 at 03:08:38PM +0200, Heinrich Schuchardt wrote:
> >> >> 
> >> >> 
> >> >> Am 4. September 2021 15:01:11 MESZ schrieb Tom Rini <trini@konsulko.com>:
> >> >> >On Sat, Sep 04, 2021 at 11:56:47AM +0200, Heinrich Schuchardt wrote:
> >> >> >
> >> >> >> Dear Tom,
> >> >> >> 
> >> >> >> The following changes since commit 94509b79b13e69c209199af0757afbde8d2ebd6d:
> >> >> >> 
> >> >> >>   btrfs: Use default subvolume as filesystem root (2021-09-01 10:11:24
> >> >> >> -0400)
> >> >> >> 
> >> >> >> are available in the Git repository at:
> >> >> >> 
> >> >> >>   https://source.denx.de/u-boot/custodians/u-boot-efi.git
> >> >> >> tags/efi-2021-10-rc4
> >> >> >> 
> >> >> >> for you to fetch changes up to 1dfa494610c5469cc28cf1f8538abf4be6c00324:
> >> >> >> 
> >> >> >>   efi_loader: fix efi_tcg2_hash_log_extend_event() parameter check
> >> >> >> (2021-09-04 09:15:09 +0200)
> >> >> >> 
> >> >> >> ----------------------------------------------------------------
> >> >> >> Pull request for efi-2021-10-rc4
> >> >> >> 
> >> >> >> Documentation:
> >> >> >> 
> >> >> >>     Remove invalid reference to configuration variable in UEFI doc
> >> >> >> 
> >> >> >> UEFI:
> >> >> >> 
> >> >> >>     Parameter checks for the EFI_TCG2_PROTOCOL
> >> >> >>     Improve support of preseeding UEFI variables.
> >> >> >>     Correct the calculation of the size of loaded images.
> >> >> >>     Allow for UEFI images with zero VirtualSize
> >> >> >> 
> >> >> >> ----------------------------------------------------------------
> >> >> >> Heinrich Schuchardt (5):
> >> >> >>       efi_loader: sections with zero VirtualSize
> >> >> >>       efi_loader: rounding of image size
> >> >> >>       efi_loader: don't load signature database from file
> >> >> >>       efi_loader: efi_auth_var_type for AuditMode, DeployedMode
> >> >> >>       efi_loader: correct determination of secure boot state
> >> >> >> 
> >> >> >> Masahisa Kojima (3):
> >> >> >>       efi_loader: add missing parameter check for EFI_TCG2_PROTOCOL api
> >> >> >>       efi_loader: fix boot_service_capability_min calculation
> >> >> >>       efi_loader: fix efi_tcg2_hash_log_extend_event() parameter check
> >> >> >
> >> >> >And I don't see Simon's revert in here either.  And he asked you about
> >> >> >that yesterday:
> >> >> >https://lore.kernel.org/r/CAPnjgZ3eRdjF0jb9S-cJK6y+feuyRyWf0hNkf2triB4DR4UFBQ@mail.gmail.com/
> >> >> >
> >> >> >So at this point, are you asserting there is nothing to revert?
> >> >> 
> >> >> Never. Simons "revert" is breaking functionality. The concept for suporting blobs in devicetrees supplied by a prior bootstage has not been defined yet.
> >> >
> >> >And to be clearer, reverting something that was introduced in one rc in
> >> >a later rc isn't breaking functionality.  U-Boot releases (well, the
> >> >non-rc ones for sure) are on a very regular schedule.  External projects
> >> >may not depend on some feature introduced at -rcN unless they're willing
> >> >to accept that some changes could happen before release.
> >> >
> >> 
> >> There is no value delivered by Simon's series. Neither does the image get smaller nor does it fix anything. If he wants to enforce a design, it must work for all use cases. But this requires some conceptual work.
> >
> >Yes, and what's the rush to not do the conceptual work?  If I recall
> >part of the thread correctly, yes, Simon didn't get his objections in
> >before the patches were merged, but it was early enough in the release
> >cycle that taking a step back and reverting was a reasonable request.
> >What he had said wouldn't have changed if he had gotten the email out a
> >few days earlier.
> >
> >So yes, please merge Simon's revert, or post and merge new more minimal
> >revert that brings things to the same functional end.  There are
> >objections to this implementation, and thus far Simon has been
> >responding all of the requests to better clarify all of the related code
> >and concepts that have been asked of him, so that in the end an
> >implementation that fulfills all of the technical requirements can be
> >created, that hopefully leaves all parties satisfied.
> 
> There is nothing wrong with the current code.
> 
> It is Simon's concept of blobs in devicetrees that is borked in that
> it ignores QEMU and any board that gets the DT from a prior boot
> stage.

Then it should be pretty easy to get Simon to withdraw his objections,
if there's such a fundamental "this is the only possible way, no
changes" path forward.

> Simon's patches have no functional end. So what do you mean by "same functional end"?

I mean the state of the EFI subsystem, prior to the code in question
being merged, without breaking the other assorted EFI changes that have
come in since then.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

  reply	other threads:[~2021-09-04 18:08 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-04  9:56 Pull request for efi-2021-10-rc4 Heinrich Schuchardt
2021-09-04 10:10 ` Heinrich Schuchardt
2021-09-06 14:31   ` Tom Rini
2021-09-04 13:01 ` Tom Rini
2021-09-04 13:08   ` Heinrich Schuchardt
2021-09-04 13:19     ` Tom Rini
2021-09-04 14:37     ` Tom Rini
2021-09-04 17:03       ` Heinrich Schuchardt
2021-09-04 17:39         ` Tom Rini
2021-09-04 18:02           ` Heinrich Schuchardt
2021-09-04 18:08             ` Tom Rini [this message]
2021-09-04 20:08               ` Ilias Apalodimas
2021-09-06  0:47                 ` AKASHI Takahiro
2021-09-09  8:56                 ` Simon Glass
2021-09-09 11:21                   ` Heinrich Schuchardt
2021-09-09 12:01                     ` Tom Rini
2021-09-09  8:56             ` Simon Glass
2021-09-09 10:52               ` Heinrich Schuchardt
2021-09-09 12:08                 ` Tom Rini
2021-09-09 20:08                   ` Simon Glass
2021-09-09 20:44                     ` Tom Rini
2021-09-09 21:22                     ` Mark Kettenis
2021-09-10 10:28                       ` François Ozog
2021-09-09 12:17               ` François Ozog
2021-09-09 20:08                 ` Simon Glass
2021-09-10 10:40                   ` François Ozog

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=20210904180825.GJ12964@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=agraf@csgraf.de \
    --cc=ilias.apalodimas@linaro.org \
    --cc=masahisa.kojima@linaro.org \
    --cc=sjg@chromium.org \
    --cc=takahiro.akashi@linaro.org \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    /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