From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 7D4A294124E for ; Thu, 16 Nov 2023 07:10:06 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=7Lgs6lvK+9ADoJ9OM7n6MFCpcElIIkSBZZ8bdNlV3uI=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:User-Agent:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type; s=20140610; t=1700118605; v=1; b=Q6xNtLJip6iHM9XZ91r+p7DdHNkNIISEanoSjrIw0jDVYOusIKXPBG79Z7TEL5SNQ4mqDifd rOHK56/cjqr/+QaTjJ3kEQ/j94iuW+6xS8ToXfHK1ffaGUAZuUjIY05BEgNjPUZDk1QT0Hi90EH AqIzMT74D9SNuhEWDS00X7eU= X-Received: by 127.0.0.2 with SMTP id F6vKYY7687511xq1lgqIMFjr; Wed, 15 Nov 2023 23:10:05 -0800 X-Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by mx.groups.io with SMTP id smtpd.web11.2035.1700118602990827967 for ; Wed, 15 Nov 2023 23:10:03 -0800 X-Received: from loongson.cn (unknown [10.40.24.149]) by gateway (Coremail) with SMTP id _____8AxDOtFwFVlJns6AA--.44787S3; Thu, 16 Nov 2023 15:09:57 +0800 (CST) X-Received: from [10.40.24.149] (unknown [10.40.24.149]) by localhost.localdomain (Coremail) with SMTP id AQAAf8BxbNxAwFVlBtpDAA--.17757S3; Thu, 16 Nov 2023 15:09:53 +0800 (CST) Message-ID: Date: Thu, 16 Nov 2023 15:09:52 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [edk2-devel] [PATCH v2 24/30] OvmfPkg/LoongArchVirt: Add platform boot manager library To: devel@edk2.groups.io, lersek@redhat.com, Gerd Hoffmann Cc: Ard Biesheuvel , Jiewen Yao , Jordan Justen , Xianglai Li , Bibo Mao References: <20231106032521.2251143-1-lichao@loongson.cn> <20231106033021.2294243-1-lichao@loongson.cn> <0e2c2f4d-c559-f9f9-881a-143eec02de4d@redhat.com> <3e97f949-1ad3-4685-901f-945d8101a7df@loongson.cn> <7cc254fe-ac77-ea93-2c8d-d9ac2549da69@redhat.com> <4c3ac39a-3ae6-91a5-10c4-c5abcadd879d@redhat.com> From: "Chao Li" In-Reply-To: <4c3ac39a-3ae6-91a5-10c4-c5abcadd879d@redhat.com> X-CM-TRANSID: AQAAf8BxbNxAwFVlBtpDAA--.17757S3 X-CM-SenderInfo: xolfxt3r6o00pqjv00gofq/1tbiAQARCGVVfCoAxwABs4 X-Coremail-Antispam: 1Uk129KBj93XoWxWry8tFy8AFyrAFyrAr1fGrX_yoW5uw1rpr 48JrWfCr1kGr1S9F48Xw40g3yF9wsayF15J3s8tryFk3Z8tFnavr1j9r1agasxCrsYva1q vr4jqw17uFsYg3gCm3ZEXasCq-sJn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3UbIjqfuFe4nvWSU5nxnvy29KBjDU0xBIdaVrnRJUUUyCb4IE77IF4wAF F20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r 1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAF wI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1l84ACjcxK6I8E87Iv67 AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AKxVW8Jr0_Cr1UM2AIxVAIcxkEcVAq 07x20xvEncxIr21l57IF6xkI12xvs2x26I8E6xACxx1lYx0E2Ix0cI8IcVAFwI0_JrI_Jr ylYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCj r7xvwVCIw2I0I7xG6c02F41l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr 1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE 14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7 IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E 87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0x ZFpf9x07UBGQDUUUUU= Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lichao@loongson.cn List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: DqMUBd5XtSfjph6G8EBe890Mx7686176AA= Content-Type: multipart/alternative; boundary="------------Qooaa3seAJpbVrp1X0lGsSiA" X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=Q6xNtLJi; dmarc=none; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io --------------Qooaa3seAJpbVrp1X0lGsSiA Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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] -=-=-=-=-=-=-=-=-=-=-=- --------------Qooaa3seAJpbVrp1X0lGsSiA Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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) | | Mute This Topic | New Topic
Your Subscription | Contact Group Owner | Unsubscribe [rebecca@openfw.io]

_._,_._,_
--------------Qooaa3seAJpbVrp1X0lGsSiA--