From: Tom Rini <trini@konsulko.com>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: "Simon Glass" <sjg@chromium.org>, "Pali Rohár" <pali@kernel.org>,
"Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
"Alexander Graf" <agraf@csgraf.de>,
"U-Boot Mailing List" <u-boot@lists.denx.de>
Subject: Re: [PATCH 7/7] efi: Make EBBR optional
Date: Mon, 28 Jun 2021 09:48:27 -0400 [thread overview]
Message-ID: <20210628134827.GA9516@bill-the-cat> (raw)
In-Reply-To: <82577bf9-dce6-3189-6b44-4a405ede3931@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1970 bytes --]
On Mon, Jun 28, 2021 at 11:48:00AM +0200, Heinrich Schuchardt wrote:
> On 6/28/21 3:48 AM, Simon Glass wrote:
> > Add a new Kconfig option for EBBR so that the naming is more explicit.
> > Make EFI_LOADER depend on it.
> >
> > Avoid enabling the options (EBBR / EFI_LOADER) by default, to save space.
>
> NAK
>
> Operating systems like Fedora, OpenBSD, FreeBSD require UEFI support.
>
> See discussion in
> https://lists.denx.de/pipermail/u-boot/2021-June/452947.html
I also think this is taking things in the wrong direction. It was an
intentional "make EFI_LOADER default when supported" when we introduced
it, and I still think that's the right overall choice. There's a whole
lot of non-customization going on when reference designs are converted
to products or other reference designs.
> > Also add dependencies on driver model and OF_CONTROL, since boards which
> > have not migrated to these should not be using new features like EBBR.
>
> Only supporting devices using the driver model in the UEFI sub-system is
> fine with me. CONFIG_BLK=y is another possible requirement.
Adding these would be good. And may allow for the code to be
simplified?
> We still have 101 defconfigs not using CONFIG_DM=y. Shouldn't they be
> eliminated?
They will be eliminated after v2022.01, following the same 2 years of
"the deadline has passed" that's being used by the board removals I've
been posting so far this year.
> We have a low number of boards using CONFIG_DM=y and
> CONFIG_OF_CONTROL=n. Shouldn't they be moved to CONFIG_OF_CONTROL=y and
> that symbol be eliminated?
No, we don't require OF_CONTROL intentionally so that other smaller
mechanisms can be used.
[snip]
> We have 274 defconfigs with CONFIG_PARTITIONS=y and CONFIG_BLK=n.
> Shouldn't they be converted or eliminated?
Some number of them will be, I think there's one or two actual funny
cases on how that code is used however.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
next prev parent reply other threads:[~2021-06-28 13:48 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-28 1:48 [PATCH 0/7] efi: Various tidy-ups and drop the default Simon Glass
2021-06-28 1:48 ` [PATCH 1/7] configs: Resync with savedefconfig Simon Glass
2021-06-28 1:48 ` [PATCH 2/7] Makefile: Drop include/asm directory as well as symlink Simon Glass
2021-06-28 1:48 ` [PATCH 3/7] disk: Tidy up #ifdefs in part_efi Simon Glass
2021-06-28 11:20 ` Heinrich Schuchardt
2021-06-28 13:50 ` Tom Rini
2021-06-28 16:18 ` Heinrich Schuchardt
2021-06-28 1:48 ` [PATCH 4/7] Use LIB_UUID with ACPIGEN and FS_BTRFS Simon Glass
2021-06-28 1:48 ` [PATCH 5/7] Allow efi_loader header to be included always Simon Glass
2021-06-28 11:02 ` Heinrich Schuchardt
2021-06-28 1:48 ` [PATCH 6/7] lib: Create a new Kconfig option for charset conversion Simon Glass
2021-06-28 10:37 ` Heinrich Schuchardt
2021-06-28 1:48 ` [PATCH 7/7] efi: Make EBBR optional Simon Glass
2021-06-28 9:48 ` Heinrich Schuchardt
2021-06-28 13:48 ` Tom Rini [this message]
2021-06-28 8:38 ` [PATCH 0/7] efi: Various tidy-ups and drop the default Mark Kettenis
2021-06-28 8:59 ` Ilias Apalodimas
2021-06-28 13:37 ` Tom Rini
2021-06-28 14:18 ` Simon Glass
2021-06-28 15:20 ` Heinrich Schuchardt
2021-06-28 16:26 ` Simon Glass
2021-06-28 17:09 ` Heinrich Schuchardt
2021-06-28 18:02 ` Simon Glass
2021-06-28 17:27 ` Tom Rini
2021-06-28 18:08 ` Simon Glass
2021-06-29 12:56 ` AKASHI Takahiro
2021-06-29 14:01 ` Heinrich Schuchardt
2021-06-29 14:14 ` AKASHI Takahiro
2021-06-28 17:49 ` Mark Kettenis
2021-07-02 19:05 ` Simon Glass
2021-07-02 19:48 ` Mark Kettenis
2021-07-02 20:09 ` Tom Rini
2021-07-02 20:47 ` Simon Glass
2021-06-28 14:25 ` Heinrich Schuchardt
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=20210628134827.GA9516@bill-the-cat \
--to=trini@konsulko.com \
--cc=agraf@csgraf.de \
--cc=ilias.apalodimas@linaro.org \
--cc=pali@kernel.org \
--cc=sjg@chromium.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 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.