Re: [PATCH 7/7] efi: Make EBBR optional

[Heinrich Schuchardt <xypron.glpk@gmx.de>]

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

>
> 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.

We still have 101 defconfigs not using CONFIG_DM=y. Shouldn't they be
eliminated?

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?

armadillo-800eva_defconfig
cm_t335_defconfig
colibri_pxa270_defconfig
devkit3250_defconfig
devkit8000_defconfig
ids8313_defconfig
integratorap_cm720t_defconfig
integratorap_cm920t_defconfig
integratorap_cm926ejs_defconfig
integratorap_cm946es_defconfig
integratorcp_cm1136_defconfig
integratorcp_cm920t_defconfig
integratorcp_cm926ejs_defconfig
integratorcp_cm946es_defconfig
kmcoge4_defconfig
kzm9g_defconfig
mx6memcal_defconfig
nokia_rx51_defconfig
snapper9260_defconfig
snapper9g20_defconfig
sniper_defconfig
vexpress_aemv8a_semi_defconfig
work_92105_defconfig
xtfpga_defconfig

We have 274 defconfigs with CONFIG_PARTITIONS=y and CONFIG_BLK=n.
Shouldn't they be converted or eliminated?

> The unwillingness to use driver model has resulted in the duplication of
> driver model code in EFI, which is part of the reason for this bloat.

Could you, please, point out where you see possibilities for code reduction.

We started with a situation where many boards were not using the driver
model. It is only this year that Tom started to eliminate boards that
don't adher to the driver model in some areas.

The semantics used in UEFI and in the rest of U-Boot differ in many
aspects. Here are some examples:

* partitions are handled in UEFI like sub-devices but the driver model
does not cover partitions yet
* to expose partitions UEFI requires fully probed block devices but
U-Boot tries to probe upon first usage
* UEFI uses file handles but U-Boot does not know this concept


Best regards

Heinrich