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 E1FAD21954068 for ; Thu, 27 Apr 2017 09:28:26 -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; Fri, 28 Apr 2017 00:28:24 +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/AAACDQ2AAADMmcAACCgMgAAZmNbAAAJJkYAACyJsgACGHa0A= Date: Thu, 27 Apr 2017 16:28:23 +0000 Message-ID: <7236196A5DF6C040855A6D96F556A53F576D79@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> <7236196A5DF6C040855A6D96F556A53F57681D@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: Thu, 27 Apr 2017 16:28:27 -0000 Content-Language: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mike -- For the one-logo case, yes, that would work. But this is the simplest case.= Consider HII string packages. Tim=20 -----Original Message----- From: Kinney, Michael D [mailto:michael.d.kinney@intel.com]=20 Sent: Wednesday, April 26, 2017 5:28 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 Tim, Could you use a PCD (for example a GUID value of an FFS file) for the Logo,= and you could use PcdGet() after SetSku() and the GUID value of the FFS fi= le with the logo would be returned for the lookup. That way, the need for the relationship information at runtime is removed a= nd you would get the behavior you describe below. Mike > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of=20 > Tim Lewis > Sent: Wednesday, April 26, 2017 4:06 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 > We select logos for SKU C (which is listed as having SKU A and=20 > DEFAULT) as its antecedents. If SKU C does not have a logo, then the=20 > SKU from SKU A is used. And if not from SKU A, then from DEFAULT. >=20 > Tim >=20 > -----Original Message----- > From: Kinney, Michael D [mailto:michael.d.kinney@intel.com] > Sent: Wednesday, April 26, 2017 3:57 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 > How would this relationship information be used in a module? > Do you have an example use case where this relationship information=20 > could be used from the selected SKU? Maybe there is a different=20 > method to solve the same problem? >=20 > Please also review the 2nd SKU related RFC titled: >=20 > [RFC 0/2] PCD: Extended SKU support 2 - sub SKU >=20 > This 2nd RFC builds on the first SKU RFC. The SKU inheritance=20 > relationships are not as straight forward when you add the concept of=20 > generating all possible combinations of SKUs from multiple subsystems. >=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 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 > > > > Mike -- > > > > So your use case for SetSku() is also what we've used. > > > > Generating a simple table that describes the default relationships=20 > > between SKUs is helpful: > > > > DEFAULT > > A DEFAULT > > B A DEFAULT > > > > This could be a #define in the form of a C UINT32 structure initializer= : > > > > #define SKUID_DEFAULT_ORDER 0,1,0,2,1,0 > > > > I think that this should be a part of this RFC. > > > > ------------- > > 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. > > > > 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=20 > > error condition that is difficult to detect. SetSku() can't do it,=20 > > because there is no guarantee (today) that the PCD driver knows all=20 > > possible SKUs, only those that have PCDs associated with them. > > > > 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=20 > > sku-identifier is not in the build. Also useful for ASL and VFR. > > > > 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_IDENT= IFIER. > > > > These might be the subject for additional RFCs. > > > > Tim > > > > -----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 > > > > Hi Tim, > > > > 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 regis= ters. > > > > Before the SKU is set, PCD services access values from the DEFAULT=20 > > SKU (SKU ID 0). After SetSku() is called, the PCD services access=20 > > values for that specific SKU. > > > > 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? > > > > What additions do you suggest to this RFC or to another RFC that=20 > > builds on top of this RFC? > > > > 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: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 -=20 > > > inheritance > > > > > > Mike -- > > > > > > I am saying that creating a relationship between SKUs that cannot=20 > > > be 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. > > > 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=20 > > > or 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=20 > > > the data. But we would like to consider any work in this area as=20 > > > a 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 implement= ation. > > > 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=20 > > > look 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=20 > > > > not SKU x, then use SKU DEFAULT. This assumption is used (by us)=20 > > > > for many purposes other than the PCD database. > > > > > > > > I'm confused by your statement that "This RFC has no impact to=20 > > > > the PCD database or behavior of PCD services." Currently, as I=20 > > > > recall, there is an optimization that says: only the differences=20 > > > > between SKU A/SKU B and SKU DEFAULT must exist in the PCD=20 > > > > database (SKU A and SKU B are sparsely encoded). Are you saying=20 > > > > that this proposed change will not, in fact, optimize the PCD=20 > > > > database for SKU B (that it will have the full set of values=20 > > > > that differ from SKU > > > > 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=20 > > > > at 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,=20 > > > > 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=20 > > > > ; edk2- devel@lists.01.org; Kinney, Michael=20 > > > > D > > > > 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 fi= le. > > > > > > > > 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=20 > > > > SKU specific PCD statement > > > is required. > > > > > > > > With this proposal, a relationship between SKUs can be declared=20 > > > > 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=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 s= yntax. > > > > 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,=20 > > > > > Liming > > > > > 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=20 > > > > > not the case. The SKU ID may be used by other components, and=20 > > > > > other components may use the > > > > > 0|DEFAULT rule as well. > > > > > > > > > > 1) There is no way to read this defaulting rule at runtime.=20 > > > > > The information is buried in the PCD database, but not available = externally. > > > > > 2) There is no way to read the contents of SKUID_IDENTIFIER=20 > > > > > when multiple SKUs are specified. While more than one SKU can=20 > > > > > be 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=20 > > > > > supported 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 -=20 > > > > > 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=20 > > > > > 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=20 > > > > > another 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 u= sage. > > > > > BaseTools update is needed to support the syntax extension,=20 > > > > > 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=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 = DEFAULT. > > > > > > > > > > [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 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel