Re: [edk2-devel] [PATCH v2 24/30] OvmfPkg/LoongArchVirt: Add platform boot manager library

["Laszlo Ersek" <lersek@redhat.com>]

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 (#111272): https://edk2.groups.io/g/devel/message/111272
Mute This Topic: https://groups.io/mt/102413902/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-