[edk2-devel] The principles of EDK2 module reconstruction for archs

Ni, Ray ray.ni at intel.com
Thu Sep 29 07:47:30 UTC 2022


Sunil, I don't have concern with your changes.
Perhaps you can also move all existing source files to X86 folder.

> -----Original Message-----
> From: devel at edk2.groups.io <devel at edk2.groups.io> On Behalf Of Sunil V L
> Sent: Wednesday, September 28, 2022 3:34 PM
> To: devel at edk2.groups.io; Ni, Ray <ray.ni at intel.com>
> Cc: abner.chang at amd.com; Kinney, Michael D
> <michael.d.kinney at intel.com>; lichao <lichao at loongson.cn>; Kirkendall,
> Garrett <Garrett.Kirkendall at amd.com>; Grimes, Paul
> <Paul.Grimes at amd.com>; He, Jiangang <Jiangang.He at amd.com>; Attar,
> AbdulLateef (Abdul Lateef) <AbdulLateef.Attar at amd.com>; Leif Lindholm
> <quic_llindhol at quicinc.com>; Andrew Fish <afish at apple.com>
> Subject: Re: [edk2-devel] The principles of EDK2 module reconstruction for
> archs
> 
> On Wed, Sep 28, 2022 at 03:33:45AM +0000, Ni, Ray wrote:
> Hi Ray,
> >
> >   1.  When a new arch's implementation is introduced to the existing
> module which was developed for the specific arch:
> >
> >   1.  The folder reconstruction:
> >
> >   *   Create arch folder for the existing arch implementation
> > [Ray] Do you move existing arch implementation to that arch folder? It will
> break existing platforms a lot.
> >
> >   *   Create the arch folder for the new introduced arch
> > [Ray] I agree. But if we don't create arch folder for existing arch
> implementation, the pkg layout will be a mess.
> >
> > [Ray] Hard for me to understand all the principles here. Maybe we review
> existing code including to-be-upstreamed code and decide how to go.
> >
> 
> Could you please take a look below changes which is trying to add RISC-V
> support for CpuDxe?
> https://github.com/tianocore/edk2-
> staging/commit/bba1a11be47dd091734e185afbed73ea75708749
> https://github.com/tianocore/edk2-
> staging/commit/7fccf92a97a6d0618a20f10622220e78b3687906
> 
> What do you suggest with above example?
> 
> 1) Common INF for all architectures - but modify INF alone, no X86
> folder creation.
> 
> This is what I have done in the commit above. May be of least impact to
> existing code
> since it is only INF change. But like you mentioned this is bit weird that X86
> files will
> remain in root folder directly along with some common files.
> 
> 2) Common INF (CpuDxe.inf) + create arch folders X86, X64, IA32, RiscV64 etc
> 
> IMO, this is probably the best approach. What would be the challenges
> with this?
> 
> 3) Separate INF for arch like CpuDxe.inf for x86, CpuDxeRiscV64.inf for
> RISC-V.
> 
> This again probably is not a good idea.
> 
> 4) If the module/library is specific to one arch (ex: SMM(X86),
> SBI(RISC-V)), then create separate INF.
> 
> Thanks!
> Sunil
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94510): https://edk2.groups.io/g/devel/message/94510
Mute This Topic: https://groups.io/mt/93872791/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-




More information about the edk2-devel-archive mailing list