From: "PierreGondois" <pierre.gondois@arm.com>
To: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>,
"devel@edk2.groups.io" <devel@edk2.groups.io>,
"Yao, Jiewen" <jiewen.yao@intel.com>,
Liming Gao <gaoliming@byosoft.com.cn>,
"Kinney, Michael D" <michael.d.kinney@intel.com>,
Sami Mujawar <sami.mujawar@arm.com>,
"Liu, Zhiguang" <zhiguang.liu@intel.com>
Subject: Re: [edk2-devel] [RFC PATCH 1/1] ArmPkg,MdePkg: move ArmLib.h to MdePkg
Date: Mon, 11 Mar 2024 10:02:58 -0700 [thread overview]
Message-ID: <dca04aa8-da41-4f9b-bb31-7227934978b7@arm.com> (raw)
In-Reply-To: <58a4fbc9-36a0-4ebd-93a4-0e00fff7d293@quicinc.com>
On 3/1/24 12:45, Leif Lindholm wrote:
> Thank you.
>
> OK, that's logically consistent.
> So we'd need an ArmLibNull in MdePkg until ArmLib itself migrates there
> (ideally subsumed into BaseLib).
From what Jiewen said, it doesn't seem that creating an ArmLibNull
in the MdePkg is necessary (unless I misunderstood).
I will send a follow-up patch to the RFC tomorrow. Along the RFC patch,
it should be sufficient to move ArmLib to the MdePkg,
Regards,
Pierre
>
> But the dependency in .inf should still be able to be declared under
> [LibraryClasses.AArch64, LibraryClasses.ARM]?
>
> Regards,
>
> Leif
>
> On 2024-03-01 01:00, Yao, Jiewen wrote:
>> Sure.
>>
>> When we say "dependency", what we really mean is the dependency in INF file, not "dependency" in DSC file.
>>
>> From package release perspective, only INF is the interface to other package.
>> The DSC is only the package internal stuff, you can create multiple DSCs or add/remove DSC freely.
>>
>> Having "dependency" in DSC does not matter.
>> Having dependency in INF is something we should care about.
>>
>> Thank you
>> Yao, Jiewen
>>
>>
>>> -----Original Message-----
>>> From: Leif Lindholm <quic_llindhol@quicinc.com>
>>> Sent: Tuesday, February 13, 2024 1:38 AM
>>> To: Pierre Gondois <pierre.gondois@arm.com>; devel@edk2.groups.io; Yao,
>>> Jiewen <jiewen.yao@intel.com>
>>> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>; Liming Gao
>>> <gaoliming@byosoft.com.cn>; Kinney, Michael D <michael.d.kinney@intel.com>;
>>> Sami Mujawar <sami.mujawar@arm.com>; Liu, Zhiguang
>>> <zhiguang.liu@intel.com>
>>> Subject: Re: [RFC PATCH 1/1] ArmPkg,MdePkg: move ArmLib.h to MdePkg
>>>
>>> Jiewen, can you clarify what you said back in
>>> https://edk2.groups.io/g/devel/message/111551
>>> ?
>>>
>>> On 2024-02-12 17:24, Pierre Gondois wrote:
>>>>>> A ArmLibNull.inf library might also need to be created. If the
>>>>>> OpensslLibFullAccel.inf module will depend on the ArmLib library,
>>>>>> a Null implementation will be necessary for non-Arm architectures.
>>>>>
>>>>> Can ArmLib be declared under a [LibraryClasses.AArch64,
>>>>> LibraryClasses.ARM]? Have I forgotten something that we discussed back
>>>>> in ... November?
>>>>
>>>> From [1], it seems the MdePkg/CryptoPkg should build without a dependency
>>>> on the ArmPkg. This is currently not really the case. cf. [2].
>>>>
>>>> However, having a ArmLibNull implementation in the MdePkg would allow to
>>>> avoid going in this direction when providing libraries to CryptoPkg.dsc.
>>>>
>>>> (Just in case, I think this ArmLibNull is a minor point.)
>>>
>>> Well, sure, it is now.
>>> Until we need a RiscV64LibNull, LoongarchLibNull, ...
>>>
>>>> [1] https://edk2.groups.io/g/devel/message/111545
>>>> [2]
>>>>
>>> https://github.com/tianocore/edk2/blob/8801c75b4d77c2e6e06b3ddc8560e0db
>>> 590f6342/CryptoPkg/CryptoPkg.dsc#L117
>>>>
>>>>>
>>>>>> Otherwise I could apply and run the CryptoPkg/Arm native instructions
>>>>>> patchset on top of this patch.
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> As a side note, it also seems that:
>>>>>> - ArmPkg/Include/Chipset/ArmCortexA5x.h
>>>>>> isn't used anymore in edk2/edk2-platorms
>>>>>> - ArmPkg/Include/Chipset/ArmCortexA9.h
>>>>>> is barely used in edk2-platforms.
>>>>>> Maybe the files should have been removed/simplified as part of
>>>>>> - cffa7925a293 ("ArmPkg: remove ArmCpuLib header and implementations")
>>>>>> - a913ad02479d ("ArmPlatformPkg: remove ArmVExpressPkg")
>>>>>
>>>>> I think you're right.
>>>>> Well, ArmCortexA9.h is still *used*, but I can't imagine the Arm branch
>>>>> of ArmVExpressLib has been build by anyone for some time. And surely the
>>>>> inclusion of ArmVExpressLibSec in ArmVExpress-FVP-AArch64.dsc is
>>>>> superfluous (such that that .inf can be deleted)?
>>>>
>>>> The file could just be moved in the Library. I assume you/Sami/Ard
>>>> will know more on the usage of the library itself,
>>>
>>> Sami?
>>>
>>> /
>>> Leif
>>>
>>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116649): https://edk2.groups.io/g/devel/message/116649
Mute This Topic: https://groups.io/mt/102731845/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
prev parent reply other threads:[~2024-03-11 17:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-21 16:42 [edk2-devel] [RFC PATCH 1/1] ArmPkg,MdePkg: move ArmLib.h to MdePkg Leif Lindholm
2023-12-21 11:13 ` PierreGondois
2024-02-09 13:25 ` PierreGondois
2024-02-09 15:05 ` Leif Lindholm
2024-02-09 15:29 ` Leif Lindholm
2024-02-12 17:24 ` PierreGondois
2024-02-12 17:37 ` Leif Lindholm
2024-02-13 9:33 ` Sami Mujawar
2024-03-01 1:00 ` Yao, Jiewen
2024-03-01 11:45 ` Leif Lindholm
2024-03-01 15:04 ` Yao, Jiewen
2024-03-11 17:02 ` PierreGondois [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dca04aa8-da41-4f9b-bb31-7227934978b7@arm.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox