From: "Sunil V L" <sunilvl@ventanamicro.com>
To: devel@edk2.groups.io, ray.ni@intel.com
Cc: "abner.chang@amd.com" <abner.chang@amd.com>,
"Kinney, Michael D" <michael.d.kinney@intel.com>,
lichao <lichao@loongson.cn>,
"Kirkendall, Garrett" <Garrett.Kirkendall@amd.com>,
"Grimes, Paul" <Paul.Grimes@amd.com>,
"He, Jiangang" <Jiangang.He@amd.com>,
"Attar, AbdulLateef (Abdul Lateef)" <AbdulLateef.Attar@amd.com>,
Leif Lindholm <quic_llindhol@quicinc.com>,
Andrew Fish <afish@apple.com>
Subject: Re: [edk2-devel] The principles of EDK2 module reconstruction for archs
Date: Wed, 28 Sep 2022 13:04:19 +0530 [thread overview]
Message-ID: <YzP4+8i3S8yV8S+Y@sunil-laptop> (raw)
In-Reply-To: <MWHPR11MB16319AA74D5CD0051CA8ED7E8C549@MWHPR11MB1631.namprd11.prod.outlook.com>
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
next prev parent reply other threads:[~2022-09-28 7:34 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-23 15:38 The principles of EDK2 module reconstruction for archs Chang, Abner
2022-09-23 18:00 ` Michael D Kinney
2022-09-26 7:33 ` Chang, Abner
2022-09-26 15:44 ` [edk2-devel] " Michael D Kinney
2022-09-27 9:25 ` Chang, Abner
2022-09-28 3:56 ` Ni, Ray
2022-09-28 4:35 ` Chang, Abner
2022-09-28 3:33 ` Ni, Ray
2022-09-28 4:30 ` [edk2-devel] " Chang, Abner
2022-09-28 5:42 ` Ni, Ray
2022-09-28 5:54 ` Chang, Abner
2022-09-28 7:34 ` Sunil V L [this message]
2022-09-28 15:00 ` Chang, Abner
2022-09-29 7:10 ` Attar, AbdulLateef (Abdul Lateef)
2022-09-29 7:42 ` Ni, Ray
2022-09-30 7:10 ` Chang, Abner
2022-09-30 15:28 ` Michael D Kinney
2022-09-30 16:08 ` Leif Lindholm
2022-09-30 18:52 ` Michael D Kinney
2022-10-03 3:13 ` Chang, Abner
2022-10-03 5:17 ` Michael D Kinney
2022-10-03 5:36 ` Chang, Abner
2022-10-03 16:54 ` Michael D Kinney
2022-10-04 14:05 ` Chang, Abner
2022-10-04 14:17 ` Michael D Kinney
2022-10-05 5:38 ` Chang, Abner
2022-10-06 8:37 ` Chang, Abner
2022-10-11 1:51 ` Ni, Ray
2022-10-11 2:20 ` Chang, Abner
2022-10-11 20:16 ` Michael D Kinney
2022-10-12 0:52 ` Chang, Abner
2022-10-12 1:09 ` Michael D Kinney
2022-10-12 1:26 ` Chang, Abner
2022-09-30 9:15 ` The principles of EDK2 module reconstruction for archs (wiki page on tianocore.github.io) Chang, Abner
2022-09-29 7:47 ` [edk2-devel] The principles of EDK2 module reconstruction for archs Ni, Ray
2022-09-29 14:54 ` Chang, Abner
2022-09-29 15:22 ` Sunil V L
2022-09-30 0:20 ` Chang, Abner
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=YzP4+8i3S8yV8S+Y@sunil-laptop \
--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