From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 6233821951CB1 for ; Wed, 26 Apr 2017 12:04:13 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2017 12:04:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,255,1488873600"; d="scan'208";a="79274136" Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by orsmga002.jf.intel.com with ESMTP; 26 Apr 2017 12:04:12 -0700 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.59]) by ORSMSX104.amr.corp.intel.com ([169.254.4.196]) with mapi id 14.03.0319.002; Wed, 26 Apr 2017 12:04:12 -0700 From: "Kinney, Michael D" To: Tim Lewis , "Zeng, Star" , "edk2-devel@lists.01.org" , "Kinney, Michael D" CC: "Gao, Liming" Thread-Topic: [RFC] PCD: Extended SKU support 1 - inheritance Thread-Index: AdK8pzAQEOD5vN6pRr2+K5rEi6Vq8wCAToJwAANxi6AAAIvDEAAAk1/AAACDQ2AAADMmcA== Date: Wed, 26 Apr 2017 19:04:11 +0000 Message-ID: References: <0C09AFA07DD0434D9E2A0C6AEB0483103B87E776@shsmsx102.ccr.corp.intel.com> <7236196A5DF6C040855A6D96F556A53F5763C0@msmail.insydesw.com.tw> <7236196A5DF6C040855A6D96F556A53F576515@msmail.insydesw.com.tw> <7236196A5DF6C040855A6D96F556A53F576579@msmail.insydesw.com.tw> In-Reply-To: <7236196A5DF6C040855A6D96F556A53F576579@msmail.insydesw.com.tw> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ctpclassification: CTP_IC x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZTdhODlmZWMtN2Y4Mi00ZjYxLTgzMWItZGE4MjNlNmQzYjAwIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6Ik10OHR0cU9zd0JuNWdaV2Q3ZURsVTRYR1ZXOUZCdzUxVmRkc3FlMXNRT3c9In0= dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.22.254.139] MIME-Version: 1.0 Subject: Re: [RFC] PCD: Extended SKU support 1 - inheritance X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 19:04:13 -0000 Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tim, If multiple SKUs are present in a FW image, in most cases A platform specific PEIM detects what SKU is present and=20 calls SetSku() for the detected SKU. The detection=20 mechanism is typically very HW specific and may involve checking straps, GPIOs, or reading ID values from registers. Before the SKU is set, PCD services access values from the DEFAULT SKU (SKU ID 0). After SetSku() is called, the PCD services access values for that specific SKU. =20 What would be the runtime use case for being able to lookup the relationships between SKUs if in a single boot only the DEFAULT SKU and the one SKU passed to SetSku() are involved? What additions do you suggest to this RFC or to another RFC that builds on top of this RFC? Thanks, Mike > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ti= m Lewis > Sent: Wednesday, April 26, 2017 11:46 AM > To: Kinney, Michael D ; Zeng, Star > ; edk2-devel@lists.01.org > Cc: Gao, Liming > Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance >=20 > Mike -- >=20 > I am saying that creating a relationship between SKUs that cannot be dete= rmined > at runtime is a confusing thing to add to the DSC. >=20 > Tim >=20 > -----Original Message----- > From: Kinney, Michael D [mailto:michael.d.kinney@intel.com] > Sent: Wednesday, April 26, 2017 11:40 AM > To: Tim Lewis ; Zeng, Star ; e= dk2- > devel@lists.01.org; Kinney, Michael D > Cc: Gao, Liming > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance >=20 > Tim, >=20 > This RFC does not change the DEFAULT behavior. If a PCD value override is= not > provided in a SKU, then the DEFAULT value is used. If this is not how you > interpret the RFC, then please provide some clarifications for the next r= evision > of this RFC. >=20 > This RFC is about reducing the number of PCD statements in a DSC file if = there > are multiple SKUs and if there is a relationship between SKUs that can be= used to > support that reduction. It is an optional new feature. You do not have = to use > it. >=20 > I consider the optimization of the PCD database from a size and performan= ce > perspective a separate topic. The implementation of this RFC does not re= quire > any changes to the PCD database format or the way PCD value lookup algori= thm in > the PCD drivers. >=20 > We do recognize that if a large number of SKUs with close relationships a= re > present in a single FW build, there may be more optimal ways to store the= data > and more efficient ways to access the data. But we would like to conside= r any > work in this area as a separate work item. Please feel free to add a Bug= zilla > feature request if you have specific ideas on how to reduce size and/or i= mprove > performance. >=20 > Given that this RFC is only about a more efficient DSC file implementatio= n. > Can you please describe your concerns with SKUs as they are currently doc= umented > in the EDK II specifications? If you have additional feature requests for= the EDK > II SKU behavior, then I look forward to seeing your detailed proposals. >=20 > Thanks, >=20 > Mike >=20 > > -----Original Message----- > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of > > Tim Lewis > > Sent: Wednesday, April 26, 2017 11:24 AM > > To: Kinney, Michael D ; Zeng, Star > > ; edk2-devel@lists.01.org > > Cc: Gao, Liming > > Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance > > > > I understand the purpose. Today there is an assumption that IF not SKU > > x, then use SKU DEFAULT. This assumption is used (by us) for many > > purposes other than the PCD database. > > > > I'm confused by your statement that "This RFC has no impact to the PCD > > database or behavior of PCD services." Currently, as I recall, there > > is an optimization that says: only the differences between SKU A/SKU B > > and SKU DEFAULT must exist in the PCD database (SKU A and SKU B are > > sparsely encoded). Are you saying that this proposed change will not, > > in fact, optimize the PCD database for SKU B (that it will have the > > full set of values that differ from SKU DEFAULT?) If so, it is a pity. > > > > My other concern is that, we use the defaulting assumption for many oth= er > items. > > For example: logos. Leaving it as a build-time construct only prevents > > other components from taking advantage of this knowledge. > > > > Tim > > > > On a separate, but related topic, the term "SKU" has a broad > > connotation, and we use it for many other items board-specific at build= -time > and run-time (ie. > > Logos). Leaving the defaulting relationship as a build-time construct > > prevents usage at runtime. This is similar run-time problem to the > > case when (a) there are > > 10 SKUs listed in [SkuIds] but (b) 3 are listed in SKUID_IDENTIFIERS > > for this particular build. How, at runtime, does C code pick up that > > SkuA is supported in the current build? > > > > > > > > > > > > -----Original Message----- > > From: Kinney, Michael D [mailto:michael.d.kinney@intel.com] > > Sent: Wednesday, April 26, 2017 11:05 AM > > To: Tim Lewis ; Zeng, Star > > ; edk2- devel@lists.01.org; Kinney, Michael D > > > > Cc: Gao, Liming > > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance > > > > Tim, > > > > Can you please provide more details on your specific concerns along > > with some use cases? > > > > This RFC does not change the SKU feature in EDK II. This RFC simply > > provides a more efficient way for a developer to provide PCD values > > for different SKUs with fewer PCD statements in a DSC file. > > > > Today, every SKU is a based on the DEFAULT SKU and if a PCD requires a > > different value than the DEFAULT SKU value, then a SKU specific PCD sta= tement > is required. > > > > With this proposal, a relationship between SKUs can be declared in the > > DSC file, so SKUs can inherit PCD values from other SKUs. This > > inheritance is limited to the scope of the DSC file. This RFC has no > > impact to the PCD database or behavior of PCD services. > > > > The example Star provides at the end shows the equivalent set of PCD > > settings using the current EDK II syntax and with this RFC's backwards > > compatible syntax extensions. > > > > One way to think about this RFC is that a DSC file using the syntax in > > this RFC can be converted to a DSC file without the RFC syntax. In > > fact, that is what the implementation of this RFC would do to build the= set of > PCD values for each SKU. > > > > Thanks, > > > > Mike > > > > > > > > > -----Original Message----- > > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf > > > Of Tim Lewis > > > Sent: Wednesday, April 26, 2017 9:21 AM > > > To: Zeng, Star ; edk2-devel@lists.01.org > > > Cc: Kinney, Michael D ; Gao, Liming > > > > > > Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance > > > > > > Star -- > > > > > > This assumes that the SKU ID is only used for PCDs, which is not the > > > case. The SKU ID may be used by other components, and other > > > components may use the > > > 0|DEFAULT rule as well. > > > > > > 1) There is no way to read this defaulting rule at runtime. The > > > information is buried in the PCD database, but not available external= ly. > > > 2) There is no way to read the contents of SKUID_IDENTIFIER when > > > multiple SKUs are specified. While more than one SKU can be > > > specified (separated by spaces), there is no way to pass multiple > > > values into build.exe today, nor is there any way to identify which > > > SKUs (out of the total list of SKUs) is supported on one build at run= time. > > > > > > Tim > > > > > > > > > -----Original Message----- > > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf > > > Of Zeng, Star > > > Sent: Tuesday, April 25, 2017 5:40 AM > > > To: edk2-devel@lists.01.org > > > Cc: Kinney, Michael D ; Zeng, Star > > > ; Gao, Liming > > > Subject: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance > > > > > > - Requirement > > > Simplify the PCDs configuring for multiple SKUs in DSC. > > > > > > > > > - Current limitation > > > Non-DEFAULT SKU could only derive from DEFAULT SKU, but could not > > > derive from another non-DEFAULT SKU. > > > For example below, SkuA and SkuB could only derive from DEFAULT, but > > > SkuB could not derive from SkuA. > > > > > > [SkuIds] > > > =A0 0 | DEFAULT > > > =A0 1 | SkuA > > > =A0 2 | SkuB > > > > > > > > > - Proposal: One non-DEFAULT SKU could be a derivative of another > > > non-DEFAULT > > SKU. > > > This proposal only extends DSC [SkuIds] section syntax and the > > > extension is optional. > > > This proposal keeps the backward compatibility with current SKU usage= . > > > BaseTools update is needed to support the syntax extension, and no > > > any change in PCD database and driver is required. > > > > > > DSC syntax: > > > [SkuIds] > > > SkuValue|SkuName[|ParentSkuName] > > > SkuValue: integer, 0 is reserved for DEFAULT SKU. > > > SkuName: string > > > ParentSkuName: string, optional, it is new introduced in this > > > proposal and defines which SKU the PCD value will derive from for > > > this SKU. The PCD value will derive from DEFAULT SKU for this SKU if > > > the > > ParentSkuName is absent. > > > > > > > > > - Example: SkuB is a derivative of SkuA, but not a derivative of DEFA= ULT. > > > > > > [SkuIds] > > > 0 | DEFAULT > > > 1 | SkuA > > > 2 | SkuB | SkuA > > > > > > [PcdsDynamicDefault.Common.DEFAULT] > > > gXXXPkgTokenSpaceGuid.PcdXXXSignature|"DEFAULT" > > > gXXXPkgTokenSpaceGuid.PcdXXXConfig1|FALSE > > > gXXXPkgTokenSpaceGuid.PcdXXXConfig2|FALSE > > > gXXXPkgTokenSpaceGuid.PcdXXXConfig3|FALSE > > > > > > [PcdsDynamicDefault.Common.SkuA] > > > gXXXPkgTokenSpaceGuid.PcdXXXSignature|"SkuA" > > > gXXXPkgTokenSpaceGuid.PcdXXXConfig1|TRUE > > > gXXXPkgTokenSpaceGuid.PcdXXXConfig2|TRUE > > > # No need statement for PcdXXXConfig3 whose value will derive > > > from DEFAULT SKU and be FLASE. > > > > > > [PcdsDynamicDefault.Common.SkuB] > > > gXXXPkgTokenSpaceGuid.PcdXXXSignature|" SkuB" > > > # No need statement for PcdXXXConfig1 and PcdXXXConfig2 whose > > > values will derive from SkuA SKU and be TRUE. > > > gXXXPkgTokenSpaceGuid.PcdXXXConfig3|TRUE > > > _______________________________________________ > > > edk2-devel mailing list > > > edk2-devel@lists.01.org > > > https://lists.01.org/mailman/listinfo/edk2-devel > > > _______________________________________________ > > > edk2-devel mailing list > > > edk2-devel@lists.01.org > > > https://lists.01.org/mailman/listinfo/edk2-devel > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel