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 7831720080EFB for ; Wed, 26 Apr 2017 11:23:35 -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:23:33 +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+K5rEi6Vq8wCAToJwAANxi6AAAIvDEA== Date: Wed, 26 Apr 2017 18:23:32 +0000 Message-ID: <7236196A5DF6C040855A6D96F556A53F576515@msmail.insydesw.com.tw> References: <0C09AFA07DD0434D9E2A0C6AEB0483103B87E776@shsmsx102.ccr.corp.intel.com> <7236196A5DF6C040855A6D96F556A53F5763C0@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:23:36 -0000 Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I understand the purpose. Today there is an assumption that IF not SKU x, t= hen use SKU DEFAULT. This assumption is used (by us) for many purposes othe= r than the PCD database. I'm confused by your statement that "This RFC has no impact to the PCD data= base or behavior of PCD services." Currently, as I recall, there is an opti= mization that says: only the differences between SKU A/SKU B and SKU DEFAUL= T must exist in the PCD database (SKU A and SKU B are sparsely encoded). Ar= e 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 fr= om SKU DEFAULT?) If so, it is a pity. My other concern is that, we use the defaulting assumption for many other i= tems. For example: logos. Leaving it as a build-time construct only prevent= s other components from taking advantage of this knowledge. Tim On a separate, but related topic, the term "SKU" has a broad connotation, a= nd 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 wh= en (a) there are 10 SKUs listed in [SkuIds] but (b) 3 are listed in SKUID_I= DENTIFIERS 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]=20 Sent: Wednesday, April 26, 2017 11:05 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, Can you please provide more details on your specific concerns along with so= me use cases? This RFC does not change the SKU feature in EDK II. This RFC simply provid= es 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 diff= erent value than the DEFAULT SKU value, then a SKU specific PCD statement i= s required.=20 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 da= tabase or behavior of PCD services. The example Star provides at the end shows the equivalent set of PCD settin= gs 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 val= ues for each SKU. =20 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 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 >=20 > Star -- >=20 > 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 components=20 > may use the > 0|DEFAULT rule as well. >=20 > 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 specified=20 > (separated by spaces), there is no way to pass multiple values into=20 > build.exe today, nor is there any way to identify which SKUs (out of=20 > the total list of SKUs) is supported on one build at runtime. >=20 > Tim >=20 >=20 > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of=20 > 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 >=20 > - Requirement > Simplify the PCDs configuring for multiple SKUs in DSC. >=20 >=20 > - 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. >=20 > [SkuIds] > =A0 0 | DEFAULT > =A0 1 | SkuA > =A0 2 | SkuB >=20 >=20 > - Proposal: One non-DEFAULT SKU could be a derivative of another non-DEFA= ULT 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 any=20 > change in PCD database and driver is required. >=20 > 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 this=20 > SKU. The PCD value will derive from DEFAULT SKU for this SKU if the Paren= tSkuName is absent. >=20 >=20 > - Example: SkuB is a derivative of SkuA, but not a derivative of DEFAULT. >=20 > [SkuIds] > 0 | DEFAULT > 1 | SkuA > 2 | SkuB | SkuA >=20 > [PcdsDynamicDefault.Common.DEFAULT] > gXXXPkgTokenSpaceGuid.PcdXXXSignature|"DEFAULT" > gXXXPkgTokenSpaceGuid.PcdXXXConfig1|FALSE > gXXXPkgTokenSpaceGuid.PcdXXXConfig2|FALSE > gXXXPkgTokenSpaceGuid.PcdXXXConfig3|FALSE >=20 > [PcdsDynamicDefault.Common.SkuA] > gXXXPkgTokenSpaceGuid.PcdXXXSignature|"SkuA" > gXXXPkgTokenSpaceGuid.PcdXXXConfig1|TRUE > gXXXPkgTokenSpaceGuid.PcdXXXConfig2|TRUE > # No need statement for PcdXXXConfig3 whose value will derive from=20 > DEFAULT SKU and be FLASE. >=20 > [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