public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Yao, Jiewen" <jiewen.yao@intel.com>
To: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Pierre Gondois <pierre.gondois@arm.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>,
	"Li, Yi1" <yi1.li@intel.com>,
	"Lu, Xiaoyu1" <xiaoyu1.lu@intel.com>,
	"Jiang, Guomin" <guomin.jiang@intel.com>,
	"Ard Biesheuvel" <ardb+tianocore@kernel.org>,
	Sami Mujawar <sami.mujawar@arm.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [edk2-devel] [PATCH v5 2/6] CryptoPkg/CryptoPkg.ci.yaml: Allow dependency upon ArmPkg
Date: Tue, 21 Nov 2023 14:46:05 +0000	[thread overview]
Message-ID: <MW4PR11MB5872C254082CE2D9FC6285B08CBBA@MW4PR11MB5872.namprd11.prod.outlook.com> (raw)
In-Reply-To: <ZVy+FKdAZLcBU2L/@qc-i7.hemma.eciton.net>

This Bugzilla is filed in 2022-10-26. Now it is 2023-11-21.
I agree with you that it is a big task. May I know what is the plan?
E.g. who is working on that? When do you expect it will be done?



According to the dependency rule, what we need is only *interface* definition, but not *implementation*.
That means the really requirement here is to move *interface* from ArmPkg to MdePkg, you can still keep the library implementation in ArmPkg. (It is just a subset of this Bugzilla)
Also, I don’t think CPUID check really matters here - since it is only implementation.

As long as, you have interface in MdePkg, then your INF can declare that interface.
You can still put real implementation in ArmPkg - no requirement to move.
That benefit is that you don’t need to add ArmPkg dependency in yaml.

Thank you
Yao, Jiewen

> -----Original Message-----
> From: Leif Lindholm <quic_llindhol@quicinc.com>
> Sent: Tuesday, November 21, 2023 10:26 PM
> To: Yao, Jiewen <jiewen.yao@intel.com>
> Cc: Pierre Gondois <pierre.gondois@arm.com>; devel@edk2.groups.io; Li, Yi1
> <yi1.li@intel.com>; Lu, Xiaoyu1 <xiaoyu1.lu@intel.com>; Jiang, Guomin
> <guomin.jiang@intel.com>; Ard Biesheuvel <ardb+tianocore@kernel.org>; Sami
> Mujawar <sami.mujawar@arm.com>; Gerd Hoffmann <kraxel@redhat.com>
> Subject: Re: [PATCH v5 2/6] CryptoPkg/CryptoPkg.ci.yaml: Allow dependency
> upon ArmPkg
> 
> Hi Jiewen,
> 
> On Tue, Nov 21, 2023 at 13:41:21 +0000, Yao, Jiewen wrote:
> > Thanks to let me know the background.
> >
> > Please be aware that there is fundamental difference between
> > dependency in INF and dependency in DSC.
> >
> > What we have previously in the ArmPkg in *DSC*. We don’t need add
> > ArmPkg in yaml.
> > However, what you try to introduce is ArmPkg in *INF*, e.g. your
> > patch v5 5/6. Then we have to add ArmPkg in yaml.
> >
> > Personally, I don’t think it is a good idea to add ArmPkg to yaml,
> > because it means that you have to pull ArmPkg when you build
> > CryptoPkg,.
> >
> > As long as what you add is industry standard, it is OK to add to
> > MdePkg, like what you did in v2. I would like to suggest this
> > approach.
> 
> Ultimately, all of ArmPkg needs to migrate to MdePkg.
> See https://bugzilla.tianocore.org/show_bug.cgi?id=4121
> But this is a BIG task.
> 
> The reason I asked Pierre to add this functionality in ArmPkg rather
> than MdePkg is because that is where the existing related discovery
> code lives. (Think of it as CPUID.)
> 
> For historical reasons, predating mine and Ard's involvement with
> edk2, this functionality (as well as other critical Arm functionality)
> lives in a library called ArmLib, under ArmPkg.
> For Ia32/X64, all such support lives in BaseLib, under MdePkg.
> 
> This is why I referred to ArmPkg as an exclave of MdePkg in my
> original reply to Pierre. And until someone untangles this, it's not
> realistic to treat ArmPkg as anything else.
> 
> And I don't think it's fair to expect Pierre to untangle this as part
> of this series. But I also don't think "Arm architectures need to
> duplicate their basic support code across multiple packages" is a
> solution.
> 
> Regards,
> 
> Leif
> 
> > But I would like to have ARM expert to check if those are really ARM
> > standard, and also have MdePkg owner check if it is acceptable.
> >
> > Thank you
> > Yao, Jiewen
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Pierre Gondois <pierre.gondois@arm.com>
> > > Sent: Tuesday, November 21, 2023 8:59 PM
> > > To: Yao, Jiewen <jiewen.yao@intel.com>; devel@edk2.groups.io; Leif
> Lindholm
> > > <quic_llindhol@quicinc.com>
> > > Cc: Li, Yi1 <yi1.li@intel.com>; Lu, Xiaoyu1 <xiaoyu1.lu@intel.com>; Jiang,
> Guomin
> > > <guomin.jiang@intel.com>; Ard Biesheuvel <ardb+tianocore@kernel.org>;
> Sami
> > > Mujawar <sami.mujawar@arm.com>; Gerd Hoffmann <kraxel@redhat.com>
> > > Subject: Re: [PATCH v5 2/6] CryptoPkg/CryptoPkg.ci.yaml: Allow dependency
> > > upon ArmPkg
> > >
> > > Hello Jiewen,
> > >
> > > On 11/21/23 12:27, Yao, Jiewen wrote:
> > > > Why CryptoPkg needs to depend on ArmPkg?
> > > >
> > > > Can we move content to MdePkg?
> > >
> > > The OpensslLib needs to discover the native instruction supported by the
> > > underlying platform before using them. This could also be done through the
> > > MdePkg as you suggested. The v2 is implemented that way:
> > > https://edk2.groups.io/g/devel/message/110953
> > >
> > > Also, as noted by Leif, it seems there is already a dependency over ArmPkg:
> > > # git grep ArmPkg CryptoPkg/
> > > CryptoPkg/CryptoPkg.dsc:  ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
> > > CryptoPkg/CryptoPkg.dsc:
> > > NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
> > > CryptoPkg/CryptoPkg.dsc:
> > > ArmSoftFloatLib|ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
> > > CryptoPkg/CryptoPkgMbedTls.dsc:
> > > NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
> > > CryptoPkg/CryptoPkgMbedTls.dsc:
> > > ArmSoftFloatLib|ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf
> > > CryptoPkg/CryptoPkgMbedTls.dsc:
> > >
> PeiServicesTablePointerLib|ArmPkg/Library/PeiServicesTablePointerLib/PeiServic
> > > esTablePointerLib.inf
> > >
> > > Both solutions suit me (discovering capabilities through ArmPkg or MdePkg),
> > > I just need to know which one is preferred,
> > >
> > > Regards,
> > > Pierre
> > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Pierre Gondois <pierre.gondois@arm.com>
> > > >> Sent: Tuesday, November 21, 2023 4:47 PM
> > > >> To: devel@edk2.groups.io
> > > >> Cc: Yao, Jiewen <jiewen.yao@intel.com>; Li, Yi1 <yi1.li@intel.com>; Lu,
> > > Xiaoyu1
> > > >> <xiaoyu1.lu@intel.com>; Jiang, Guomin <guomin.jiang@intel.com>; Leif
> > > Lindholm
> > > >> <quic_llindhol@quicinc.com>; Ard Biesheuvel
> <ardb+tianocore@kernel.org>;
> > > >> Sami Mujawar <sami.mujawar@arm.com>; Gerd Hoffmann
> > > >> <kraxel@redhat.com>
> > > >> Subject: [PATCH v5 2/6] CryptoPkg/CryptoPkg.ci.yaml: Allow dependency
> upon
> > > >> ArmPkg
> > > >>
> > > >> Allow dependency upon ArmPkg to pass the dependency Check.
> > > >>
> > > >> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
> > > >> ---
> > > >>   CryptoPkg/CryptoPkg.ci.yaml | 1 +
> > > >>   1 file changed, 1 insertion(+)
> > > >>
> > > >> diff --git a/CryptoPkg/CryptoPkg.ci.yaml b/CryptoPkg/CryptoPkg.ci.yaml
> > > >> index f961d85927c0..3bbb220d3224 100644
> > > >> --- a/CryptoPkg/CryptoPkg.ci.yaml
> > > >> +++ b/CryptoPkg/CryptoPkg.ci.yaml
> > > >> @@ -69,6 +69,7 @@
> > > >>       },
> > > >>
> > > >>       "DependencyCheck": {
> > > >>
> > > >>           "AcceptableDependencies": [
> > > >>
> > > >> +            "ArmPkg/ArmPkg.dec",
> > > >>
> > > >>               "MdePkg/MdePkg.dec",
> > > >>
> > > >>               "MdeModulePkg/MdeModulePkg.dec",
> > > >>
> > > >>               "CryptoPkg/CryptoPkg.dec",
> > > >>
> > > >> --
> > > >> 2.25.1
> > > >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#111551): https://edk2.groups.io/g/devel/message/111551
Mute This Topic: https://groups.io/mt/102725178/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



  reply	other threads:[~2023-11-21 14:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-21  8:47 [edk2-devel] [PATCH v5 0/6] CryptoPkg: Enable Openssl native instruction support for AARCH64 PierreGondois
2023-11-21  8:47 ` [edk2-devel] [PATCH v5 1/6] ArmPkg/ArmLib: Add macros/helper functions around AA64Isar0 register PierreGondois
2023-11-21  8:47 ` [edk2-devel] [PATCH v5 2/6] CryptoPkg/CryptoPkg.ci.yaml: Allow dependency upon ArmPkg PierreGondois
2023-11-21 11:27   ` Yao, Jiewen
2023-11-21 12:59     ` PierreGondois
2023-11-21 13:41       ` Yao, Jiewen
2023-11-21 14:26         ` Leif Lindholm
2023-11-21 14:46           ` Yao, Jiewen [this message]
2023-11-21 15:55             ` Leif Lindholm
2023-11-21 16:02               ` Ard Biesheuvel
2023-11-21 16:26                 ` Yao, Jiewen
2023-11-21  8:47 ` [edk2-devel] [PATCH v5 3/6] CryptoPkg/OpensslLib: Add native instruction support for AARCH64 PierreGondois
2023-11-21  8:47 ` [edk2-devel] [PATCH v5 4/6] CryptoPkg/OpensslLib: Generate files for AARCH64 native support PierreGondois
2023-11-21  8:47 ` [edk2-devel] [PATCH v5 5/6] CryptoPkg/OpensslLib: Add AArch64Cap for arch specific hooks PierreGondois
2023-11-21  8:47 ` [edk2-devel] [PATCH v5 6/6] CryptoPkg: Enable Openssl Accel builds for AARCH64 PierreGondois
2023-11-21 16:22 ` [edk2-devel] [PATCH v5 0/6] CryptoPkg: Enable Openssl native instruction support " Ard Biesheuvel

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=MW4PR11MB5872C254082CE2D9FC6285B08CBBA@MW4PR11MB5872.namprd11.prod.outlook.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