Hi Laszlo,
OK, I will do plan B. Moved ARM version to OvmfPkg/Library/ and rename
it to PlatformBootManagerLibLight.
Thanks,
Chao
On 2023/11/15 20:52, Laszlo Ersek wrote:
Hi Chao,
On 11/15/23 04:21, Chao Li wrote:
Well, let's discuss the ARM version name once moved.
I have two plans:
*Plan A:*
Merge the ARM version into PlatformBootmanagerLib and modify the inf
file to separate X64 and other ARCH, like be:
[Sources.Common]
QemuKernel.c
BdsPlatform.h
[Sources.X64, Sources.IA32]
BdsPlatform.c
PaltformData.c
[Sources.ARM, Sources.AARCH64, Sources.RISCV64, Source.LOONGARCH64]
PlatformBm.c
[LibraryClasses.Common]
BaseLib
BaseMemoryLib
BootLogoLib
DebugLib
DevicePathLib
MemoryAllocationLib
PcdLib
...
[LibraryClasses.X64, LibraryClasses.IA32]
QemuFwCfgLib
QemuFwCfgS3Lib
...
[LibraryClasses.ARM, LibraryClasses.AARCH64, LibraryClasses.RISCV,
LibraryClasses.LOONGARCH64]
TpmPlatformHierarchyLib
...
The above pseudocode are unverified and will definitely be subject to
modification.
*Plan B:*
Moved the ARM version into OvmfPkg and got a new name. In my opinion,
the X86 version takes into account the STR, Tcg2 and Xen platform, so it
look like more complete(only for X86, just my opinion). In this case, I
think what about the X86 version still being named
PlatformBootManagerLib and the ARM version being named
PlatformBootManagerLibLight?
Both of the above plans can achieve the goal. I prefer Plan A. I want to
know your opinions, so hope hear back from you!
I prefer Plan B.
ArmVirtPkg's PlatformBootManagerLib instance does not carry the cruft
that had accumulated in OVMF's instance (before we created ArmVirtPkg's
instance), and that has continued growing in OVMF's instance since we
created ArmVirtPkg's instance. I'm sure there are some bits that are
duplicated between both platforms, but in this case, the benefits of the
separation strongly outweigh any disadvantages of code duplication, for
me anyway.
Whenever I want to refer to a pristine PlatformBootManagerLib instance,
I use ArmVirtPkg's. I like *not* being tripped up by the quirks and
customizations of OvmfPkg's lib instance, whenever I look at the source
code. Even if we could find technical solutions for disabling those
customizations for ArmVirt at build time or at runtime, they'd still be
unwelcome distractions, when reading the source code, or browsing the
edk2 directory tree.
There is no generic rule for deciding between "customization in place"
vs. "duplicating for customization". Both have benefits and costs.
AFAICT, we usually pick one versus the other based on "audience
homogeneity" -- the code structure is supposed to follow the community
structure.
In this case, I prefer Plan B.
Thanks,
Laszlo
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111302): https://edk2.groups.io/g/devel/message/111302
Mute This Topic: https://groups.io/mt/102413902/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
