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 71C862195406C for ; Wed, 26 Apr 2017 16:06:30 -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 07:06:27 +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/AAACDQ2AAADMmcAACCgMgAAZmNbAAAJJkYA== Date: Wed, 26 Apr 2017 23:06:26 +0000 Message-ID: <7236196A5DF6C040855A6D96F556A53F57681D@msmail.insydesw.com.tw> References: <0C09AFA07DD0434D9E2A0C6AEB0483103B87E776@shsmsx102.ccr.corp.intel.com> <7236196A5DF6C040855A6D96F556A53F5763C0@msmail.insydesw.com.tw> <7236196A5DF6C040855A6D96F556A53F576515@msmail.insydesw.com.tw> <7236196A5DF6C040855A6D96F556A53F576579@msmail.insydesw.com.tw> <7236196A5DF6C040855A6D96F556A53F57664A@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 23:06:31 -0000 Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mike -- We select logos for SKU C (which is listed as having SKU A and DEFAULT) as = its antecedents. If SKU C does not have a logo, then the SKU from SKU A is = used. And if not from SKU A, then from DEFAULT. Tim -----Original Message----- From: Kinney, Michael D [mailto:michael.d.kinney@intel.com]=20 Sent: Wednesday, April 26, 2017 3:57 PM 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 Hi Tim, How would this relationship information be used in a module? Do you have an example use case where this relationship information could b= e used from the selected SKU? Maybe there is a different method to solve t= he same problem? Please also review the 2nd SKU related RFC titled: [RFC 0/2] PCD: Extended SKU support 2 - sub SKU This 2nd RFC builds on the first SKU RFC. The SKU inheritance relationship= s are not as straight forward when you add the concept of generating all po= ssible combinations of SKUs from multiple subsystems. 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 12:59 PM > 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 > Mike -- >=20 > So your use case for SetSku() is also what we've used. >=20 > Generating a simple table that describes the default relationships=20 > between SKUs is helpful: >=20 > DEFAULT > A DEFAULT > B A DEFAULT >=20 > This could be a #define in the form of a C UINT32 structure initializer: >=20 > #define SKUID_DEFAULT_ORDER 0,1,0,2,1,0 >=20 > I think that this should be a part of this RFC. >=20 > ------------- > Having said that, we've used multi-SKU for a long time and there are=20 > common error cases that could be aided by some tool support. >=20 > 1) When an image is designed to support SKUs A, B, C (out of a=20 > possible set of SKU A-H), but the SKU detected is: G. This is an error=20 > condition that is difficult to detect. SetSku() can't do it, because=20 > there is no guarantee (today) that the PCD driver knows all possible=20 > SKUs, only those that have PCDs associated with them. >=20 > 2) When C code is designed to run for SKUs A, B, D, H, the image was=20 > built for A,B,C and the SKU detected during POST was D. By having a=20 > macro that returns whether board X is supported, code which is not=20 > used for the current build can be eliminated from the build. For=20 > example. #define SKU_NAME_SUPPORTED(sku- > identifier) can return FALSE if the SKU associated with sku-identifier=20 > is not in the build. Also useful for ASL and VFR. >=20 > 3) We have also found it useful to extend the build.exe command-line=20 > to allow multiple instances of -x to correctly populate the SKUID_IDENTIF= IER. >=20 > These might be the subject for additional RFCs. >=20 > Tim >=20 > -----Original Message----- > From: Kinney, Michael D [mailto:michael.d.kinney@intel.com] > Sent: Wednesday, April 26, 2017 12:04 PM > 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 > Hi Tim, >=20 > If multiple SKUs are present in a FW image, in most cases A platform=20 > specific PEIM detects what SKU is present and calls SetSku() for the=20 > detected SKU. The detection mechanism is typically very HW specific=20 > and may involve checking straps, GPIOs, or reading ID values from registe= rs. >=20 > Before the SKU is set, PCD services access values from the DEFAULT SKU=20 > (SKU ID 0). After SetSku() is called, the PCD services access values=20 > for that specific SKU. >=20 > What would be the runtime use case for being able to lookup the=20 > relationships between SKUs if in a single boot only the DEFAULT SKU=20 > and the one SKU passed to > SetSku() are involved? >=20 > What additions do you suggest to this RFC or to another RFC that=20 > builds on top of this RFC? >=20 > Thanks, >=20 > Mike >=20 > > -----Original Message----- > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf=20 > > Of Tim Lewis > > Sent: Wednesday, April 26, 2017 11:46 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 > > > > Mike -- > > > > I am saying that creating a relationship between SKUs that cannot be=20 > > determined at runtime is a confusing thing to add to the DSC. > > > > Tim > > > > -----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=20 > > ; edk2- devel@lists.01.org; Kinney, Michael D=20 > > > > 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=20 > > override is not provided in a SKU, then the DEFAULT value is used.=20 > > If this is not how you interpret the RFC, then please provide some=20 > > clarifications for the next revision of this RFC. > > > > This RFC is about reducing the number of PCD statements in a DSC=20 > > file if there are multiple SKUs and if there is a relationship=20 > > between SKUs that can be used to support that reduction. It is an=20 > > optional new feature. You do not have to use it. > > > > I consider the optimization of the PCD database from a size and=20 > > performance perspective a separate topic. The implementation of=20 > > this RFC does not require any changes to the PCD database format or=20 > > the way PCD value lookup algorithm in the PCD drivers. > > > > We do recognize that if a large number of SKUs with close=20 > > relationships are present in a single FW build, there may be more=20 > > optimal ways to store the data and more efficient ways to access the=20 > > data. But we would like to consider any work in this area as a=20 > > separate work item. Please feel free to add a Bugzilla feature=20 > > request if you have specific ideas on how to reduce size and/or=20 > > improve > performance. > > > > Given that this RFC is only about a more efficient DSC file implementat= ion. > > Can you please describe your concerns with SKUs as they are=20 > > currently documented in the EDK II specifications? If you have=20 > > additional feature requests for the EDK II SKU behavior, then I look=20 > > forward to seeing > your detailed proposals. > > > > Thanks, > > > > Mike > > > > > -----Original Message----- > > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On=20 > > > Behalf Of 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 -=20 > > > inheritance > > > > > > I understand the purpose. Today there is an assumption that IF not=20 > > > SKU x, then use SKU DEFAULT. This assumption is used (by us) for=20 > > > many purposes other than the PCD database. > > > > > > I'm confused by your statement that "This RFC has no impact to the=20 > > > PCD database or behavior of PCD services." Currently, as I recall,=20 > > > there is an optimization that says: only the differences between=20 > > > SKU A/SKU B and SKU DEFAULT must exist in the PCD database (SKU A=20 > > > and SKU B are sparsely encoded). Are you saying that this proposed=20 > > > change will not, in fact, optimize the PCD database for SKU B=20 > > > (that it will have the full set of values that differ from SKU=20 > > > DEFAULT?) If so, it > is a pity. > > > > > > My other concern is that, we use the defaulting assumption for=20 > > > many other > > items. > > > For example: logos. Leaving it as a build-time construct only=20 > > > prevents other components from taking advantage of this knowledge. > > > > > > Tim > > > > > > 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=20 > > > build-time > > and run-time (ie. > > > Logos). Leaving the defaulting relationship as a build-time=20 > > > construct prevents usage at runtime. This is similar run-time=20 > > > problem to the case when (a) there are > > > 10 SKUs listed in [SkuIds] but (b) 3 are listed in=20 > > > SKUID_IDENTIFIERS for this particular build. How, at runtime, does=20 > > > 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=20 > > > ; edk2- devel@lists.01.org; Kinney, Michael D=20 > > > > > > Cc: Gao, Liming > > > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance > > > > > > Tim, > > > > > > Can you please provide more details on your specific concerns=20 > > > along with some use cases? > > > > > > This RFC does not change the SKU feature in EDK II. This RFC=20 > > > simply provides a more efficient way for a developer to provide=20 > > > 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=20 > > > requires a different value than the DEFAULT SKU value, then a SKU=20 > > > specific PCD statement > > is required. > > > > > > With this proposal, a relationship between SKUs can be declared in=20 > > > the DSC file, so SKUs can inherit PCD values from other SKUs. =20 > > > This inheritance is limited to the scope of the DSC file. This=20 > > > 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=20 > > > PCD settings using the current EDK II syntax and with this RFC's=20 > > > backwards compatible syntax extensions. > > > > > > One way to think about this RFC is that a DSC file using the=20 > > > syntax in this RFC can be converted to a DSC file without the RFC syn= tax. > > > In fact, that is what the implementation of this RFC would do to=20 > > > build the set of > > PCD values for each SKU. > > > > > > Thanks, > > > > > > Mike > > > > > > > > > > > > > -----Original Message----- > > > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On=20 > > > > 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=20 > > > > > > > > Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 -=20 > > > > inheritance > > > > > > > > Star -- > > > > > > > > This assumes that the SKU ID is only used for PCDs, which is not=20 > > > > the 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 extern= ally. > > > > 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=20 > > > > multiple values into build.exe today, nor is there any way to=20 > > > > identify which SKUs (out of the total list of SKUs) is supported=20 > > > > on one build at > runtime. > > > > > > > > Tim > > > > > > > > > > > > -----Original Message----- > > > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On=20 > > > > Behalf 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=20 > > > > not derive from another non-DEFAULT SKU. > > > > For example below, SkuA and SkuB could only derive from DEFAULT,=20 > > > > 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=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 usa= ge. > > > > BaseTools update is needed to support the syntax extension, and=20 > > > > 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=20 > > > > this proposal and defines which SKU the PCD value will derive=20 > > > > from for this SKU. The PCD value will derive from DEFAULT SKU=20 > > > > for this SKU if the > > > ParentSkuName is absent. > > > > > > > > > > > > - Example: SkuB is a derivative of SkuA, but not a derivative of DE= FAULT. > > > > > > > > [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=20 > > > > derive from DEFAULT SKU and be FLASE. > > > > > > > > [PcdsDynamicDefault.Common.SkuB] > > > > gXXXPkgTokenSpaceGuid.PcdXXXSignature|" SkuB" > > > > # No need statement for PcdXXXConfig1 and PcdXXXConfig2=20 > > > > 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 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel