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

["Chao Li" <lichao@loongson.cn>]

[-- Attachment #1: Type: text/plain, Size: 3495 bytes --]

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/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



[-- Attachment #2: Type: text/html, Size: 4469 bytes --]