Hi Laszlo,
OK, I will do plan B. Moved ARM version to
OvmfPkg/Library/ and rename it to PlatformBootManagerLibLight.
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