From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) by mx.groups.io with SMTP id smtpd.web09.5311.1664350468819911504 for ; Wed, 28 Sep 2022 00:34:28 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@ventanamicro.com header.s=google header.b=WflROZa/; spf=pass (domain: ventanamicro.com, ip: 209.85.216.42, mailfrom: sunilvl@ventanamicro.com) Received: by mail-pj1-f42.google.com with SMTP id u92so2266945pjh.3 for ; Wed, 28 Sep 2022 00:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date; bh=pcCYdtFTXfPVzyg8G5dsq1IbBmvWWWiZwsusCAdBwWY=; b=WflROZa/ui55W50Ua20Y99/8Zfyx0eqSAdpIj9N8q07aH26JUWS9yNBWosIhrg82/6 SJq96yPD1YluzZrjGF3+dFg/bmdXM5ERazTXOaO37OyKD32IGupUoR1hH0drfBZ3+esf Kpd+nRDhzACqyjWyBCXHQhYiXRtv0OAAeC1lCD0LSPdrrK+tGUrDu1NUxnyqdlgrslGa rg5SZ8oq+KblyfsjkRBEWBdpqhsUj5c92d9ftvTlvqCKb2hMBIQttCFdyNIx6VxUzjbE bqQDfANIlS7L0N1LVpAOQUr1sj23K2HiFeCTL/d1JfjYeWkW+szIVH+vfOKhH6lZt841 4f+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=pcCYdtFTXfPVzyg8G5dsq1IbBmvWWWiZwsusCAdBwWY=; b=zspkGp34ITM3JXoYL6XpVs2DJ3lCXip5cF8t5RiyDy/uhXYYWVPL7q18fmbjp+DYP1 weKkN3vaY0izLX6dtWhOfeFWIrIaQlCD84UN6m4r9pBZDAWAclNipBgVnoJAD3U2+YaW Uatn+eMCL/uIX2Gwzpn77QcaCb044O1OYwWY2lio/5Rnzyhun/Tjp6ncOFG6ClE/F5qz q3orK5BrkPeCHOSmpDk1pQda50ZGtkZyh7/lVlIiupZPv0vb4/D4glMsmgXZyIInkBiv EvtQmde0HEvRJiuyYz6A98Pqz/fO8tkW6LZeVoUO3npbkQ+PDb77kwulwji7p2wqQA2M Tnow== X-Gm-Message-State: ACrzQf1r0KI5QxOypmKWY69Du37aEXf/+GAi2c8U1ImwCpL91deQ1TX8 gYo6Nm/0AYyvwT8EIk7Lmx6b2zbbKe8wcQ== X-Google-Smtp-Source: AMsMyM6OXaDSDgSt2s0hTeNqsRVU6h3ZTIHzBoFBcSTVQWKEuF1RWjs2xQDGYoGJl4lNI/rHp8WUzg== X-Received: by 2002:a17:90b:4b11:b0:202:998b:71b1 with SMTP id lx17-20020a17090b4b1100b00202998b71b1mr9194191pjb.208.1664350468157; Wed, 28 Sep 2022 00:34:28 -0700 (PDT) Return-Path: Received: from sunil-laptop ([49.206.11.215]) by smtp.gmail.com with ESMTPSA id n2-20020a622702000000b0053653c6b9f9sm3143294pfn.204.2022.09.28.00.34.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Sep 2022 00:34:27 -0700 (PDT) Date: Wed, 28 Sep 2022 13:04:19 +0530 From: "Sunil V L" To: devel@edk2.groups.io, ray.ni@intel.com Cc: "abner.chang@amd.com" , "Kinney, Michael D" , lichao , "Kirkendall, Garrett" , "Grimes, Paul" , "He, Jiangang" , "Attar, AbdulLateef (Abdul Lateef)" , Leif Lindholm , Andrew Fish Subject: Re: [edk2-devel] The principles of EDK2 module reconstruction for archs Message-ID: References: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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