From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [PATCH 2/2] efi_loader: make the UEFI boot manager configurable
Date: Mon, 18 Jan 2021 11:21:56 -0500 [thread overview]
Message-ID: <20210118162156.GT9782@bill-the-cat> (raw)
In-Reply-To: <269776d1-0ff9-6460-bf45-68e626f2ff13@gmx.de>
On Fri, Jan 15, 2021 at 09:31:19PM +0100, Heinrich Schuchardt wrote:
> On 1/15/21 7:43 PM, Tom Rini wrote:
> > On Fri, Jan 15, 2021 at 07:02:50PM +0100, Heinrich Schuchardt wrote:
> >
> > > Some boards are very tight on the binary size. Booting via UEFI is possible
> > > without using the boot manager.
> >
> > While I don't think we need to re-word this part, for the record my
> > concern is global, not specific platforms. To re-iterate something we
> > talked about on IRC, I think it's important to be able to select and
> > have a default UEFI implementation that covers as many common use cases
> > as possible, while also being as small as possible.
> >
> > >
> > > Provide a configuration option to make the boot manager available.
> > >
> > > Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> > [snip]
> > > +config CMD_BOOTEFI_BOOTMGR
> > > + bool "UEFI Boot Manager"
> > > + default y
> > > + help
> > > + Select this option if you want to select the UEFI binary to be booted
> > > + via UEFI variables Boot####, BootOrder, and BootNext. This enables the
> > > + 'bootefi bootmgr' command.
> >
> > I'm not sure this should be default y. My concern is that the default
> > set of options is growing so that every possible case has support in the
> > binary but the hardware and practical use means we don't need all of
> > that. This should perhaps be "default y if DISTRO_DEFAULTS" at least.
>
> If you want to default something to no, I think that
> EFI_UNICODE_CAPITALIZATION is a better candidate.
>
> On wandboard_defconfig:
>
> 683976 - 680228 = 3748 bytes saved.
OK, thanks. Can you make up a patch with sufficient explanation of why
it's OK to not support this by default?
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210118/10e669b7/attachment.sig>
next prev parent reply other threads:[~2021-01-18 16:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-15 18:02 [PATCH 0/2] efi_loader: make the UEFI boot manager configurable Heinrich Schuchardt
2021-01-15 18:02 ` [PATCH 1/2] efi_loader: move load options to new module Heinrich Schuchardt
2021-01-18 2:17 ` AKASHI Takahiro
2021-01-18 7:38 ` Heinrich Schuchardt
2021-01-19 7:42 ` Ilias Apalodimas
2021-01-19 11:03 ` Heinrich Schuchardt
2021-01-15 18:02 ` [PATCH 2/2] efi_loader: make the UEFI boot manager configurable Heinrich Schuchardt
2021-01-15 18:43 ` Tom Rini
2021-01-15 20:31 ` Heinrich Schuchardt
2021-01-18 16:21 ` Tom Rini [this message]
2021-01-18 2:33 ` [PATCH 0/2] " AKASHI Takahiro
2021-01-18 12:54 ` 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=20210118162156.GT9782@bill-the-cat \
--to=trini@konsulko.com \
--cc=u-boot@lists.denx.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