From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from msmail.insydesw.com.tw (ms.insydesw.com [211.75.113.220]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3D0C32095C6AB for ; Wed, 26 Apr 2017 11:46:04 -0700 (PDT) Received: from msmail.insydesw.com.tw ([fe80::74f7:f173:f4aa:9a05]) by msmail.insydesw.com.tw ([fe80::74f7:f173:f4aa:9a05%11]) with mapi id 14.01.0438.000; Thu, 27 Apr 2017 02:46:02 +0800 From: Tim Lewis To: "Kinney, Michael D" , "Zeng, Star" , "edk2-devel@lists.01.org" CC: "Gao, Liming" Thread-Topic: [RFC] PCD: Extended SKU support 1 - inheritance Thread-Index: AdK8pzAQEOD5vN6pRr2+K5rEi6Vq8wCAToJwAANxi6AAAIvDEAAAk1/AAACDQ2A= Date: Wed, 26 Apr 2017 18:46:01 +0000 Message-ID: <7236196A5DF6C040855A6D96F556A53F576579@msmail.insydesw.com.tw> References: <0C09AFA07DD0434D9E2A0C6AEB0483103B87E776@shsmsx102.ccr.corp.intel.com> <7236196A5DF6C040855A6D96F556A53F5763C0@msmail.insydesw.com.tw> <7236196A5DF6C040855A6D96F556A53F576515@msmail.insydesw.com.tw> In-Reply-To: Accept-Language: en-US, zh-TW X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.100.107] 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 18:46:05 -0000 Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mike -- I am saying that creating a relationship between SKUs that cannot be determ= ined at runtime is a confusing thing to add to the DSC. Tim -----Original Message----- From: Kinney, Michael D [mailto:michael.d.kinney@intel.com]=20 Sent: Wednesday, April 26, 2017 11:40 AM To: Tim Lewis ; Zeng, Star ; edk= 2-devel@lists.01.org; Kinney, Michael D Cc: Gao, Liming Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance Tim, This RFC does not change the DEFAULT behavior. If a PCD value override is n= ot provided in a SKU, then the DEFAULT value is used. If this is not how yo= u interpret the RFC, then please provide some clarifications for the next r= evision of this RFC. This RFC is about reducing the number of PCD statements in a DSC file if th= ere 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. I consider the optimization of the PCD database from a size and performance= perspective a separate topic. The implementation of this RFC does not req= uire any changes to the PCD database format or the way PCD value lookup alg= orithm in the PCD drivers. We do recognize that if a large number of SKUs with close relationships are= 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 cons= ider any work in this area as a separate work item. Please feel free to ad= d a Bugzilla feature request if you have specific ideas on how to reduce si= ze and/or improve performance. Given that this RFC is only about a more efficient DSC file implementation. Can you please describe your concerns with SKUs as they are currently docum= ented 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 p= roposals. Thanks, Mike > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of=20 > Tim Lewis > Sent: Wednesday, April 26, 2017 11:24 AM > To: Kinney, Michael D ; Zeng, Star=20 > ; edk2-devel@lists.01.org > Cc: Gao, Liming > Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance >=20 > I understand the purpose. Today there is an assumption that IF not SKU=20 > x, then use SKU DEFAULT. This assumption is used (by us) for many=20 > purposes other than the PCD database. >=20 > I'm confused by your statement that "This RFC has no impact to the PCD=20 > database or behavior of PCD services." Currently, as I recall, there=20 > is an optimization that says: only the differences between SKU A/SKU B=20 > and SKU DEFAULT must exist in the PCD database (SKU A and SKU B are=20 > sparsely encoded). Are you saying that this proposed change will not,=20 > in fact, optimize the PCD database for SKU B (that it will have the=20 > full set of values that differ from SKU DEFAULT?) If so, it is a pity. >=20 > My other concern is that, we use the defaulting assumption for many other= items. > For example: logos. Leaving it as a build-time construct only prevents=20 > other components from taking advantage of this knowledge. >=20 > Tim >=20 > On a separate, but related topic, the term "SKU" has a broad=20 > connotation, and we use it for many other items board-specific at build-t= ime and run-time (ie. > Logos). Leaving the defaulting relationship as a build-time construct=20 > prevents usage at runtime. This is similar run-time problem to the=20 > case when (a) there are > 10 SKUs listed in [SkuIds] but (b) 3 are listed in SKUID_IDENTIFIERS=20 > for this particular build. How, at runtime, does C code pick up that=20 > SkuA is supported in the current build? >=20 >=20 >=20 >=20 >=20 > -----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=20 > ; edk2- devel@lists.01.org; Kinney, Michael D=20 > > Cc: Gao, Liming > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance >=20 > Tim, >=20 > Can you please provide more details on your specific concerns along=20 > with some use cases? >=20 > This RFC does not change the SKU feature in EDK II. This RFC simply=20 > provides a more efficient way for a developer to provide PCD values=20 > for different SKUs with fewer PCD statements in a DSC file. >=20 > Today, every SKU is a based on the DEFAULT SKU and if a PCD requires a=20 > different value than the DEFAULT SKU value, then a SKU specific PCD state= ment is required. >=20 > With this proposal, a relationship between SKUs can be declared in the=20 > DSC file, so SKUs can inherit PCD values from other SKUs. This=20 > inheritance is limited to the scope of the DSC file. This RFC has no=20 > impact to the PCD database or behavior of PCD services. >=20 > The example Star provides at the end shows the equivalent set of PCD=20 > settings using the current EDK II syntax and with this RFC's backwards=20 > compatible syntax extensions. >=20 > One way to think about this RFC is that a DSC file using the syntax in=20 > this RFC can be converted to a DSC file without the RFC syntax. In=20 > fact, that is what the implementation of this RFC would do to build the s= et of PCD values for each SKU. >=20 > Thanks, >=20 > Mike >=20 >=20 >=20 > > -----Original Message----- > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf=20 > > 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=20 > > > > 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=20 > > case. The SKU ID may be used by other components, and other=20 > > components may use the > > 0|DEFAULT rule as well. > > > > 1) There is no way to read this defaulting rule at runtime. The=20 > > information is buried in the PCD database, but not available externally= . > > 2) There is no way to read the contents of SKUID_IDENTIFIER when=20 > > multiple SKUs are specified. While more than one SKU can be=20 > > specified (separated by spaces), there is no way to pass multiple=20 > > values into build.exe today, nor is there any way to identify which=20 > > SKUs (out of the total list of SKUs) is supported on one build at runti= me. > > > > Tim > > > > > > -----Original Message----- > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf=20 > > Of Zeng, Star > > Sent: Tuesday, April 25, 2017 5:40 AM > > To: edk2-devel@lists.01.org > > Cc: Kinney, Michael D ; Zeng, Star=20 > > ; 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=20 > > derive from another non-DEFAULT SKU. > > For example below, SkuA and SkuB could only derive from DEFAULT, but=20 > > 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=20 > > non-DEFAULT > SKU. > > This proposal only extends DSC [SkuIds] section syntax and the=20 > > extension is optional. > > This proposal keeps the backward compatibility with current SKU usage. > > BaseTools update is needed to support the syntax extension, and no=20 > > 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=20 > > proposal and defines which SKU the PCD value will derive from for=20 > > this SKU. The PCD value will derive from DEFAULT SKU for this SKU if=20 > > the > ParentSkuName is absent. > > > > > > - Example: SkuB is a derivative of SkuA, but not a derivative of DEFAUL= T. > > > > [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=20 > > from DEFAULT SKU and be FLASE. > > > > [PcdsDynamicDefault.Common.SkuB] > > gXXXPkgTokenSpaceGuid.PcdXXXSignature|" SkuB" > > # No need statement for PcdXXXConfig1 and PcdXXXConfig2 whose=20 > > 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