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 D0F0221A070BA for ; Fri, 5 May 2017 09:06:05 -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; Sat, 6 May 2017 00:06:03 +0800 From: Tim Lewis To: "Zeng, Star" , "Kinney, Michael D" , "edk2-devel@lists.01.org" CC: "Gao, Liming" Thread-Topic: [RFC] PCD: Extended SKU support 1 - inheritance Thread-Index: AdK8pzAQEOD5vN6pRr2+K5rEi6Vq8wCAToJwAANxi6AAAIvDEAAAk1/AAACDQ2AAADMmcAACCgMgAAZmNbAAAJJkYAACyJsgACGHa0AAEcFR8AABsp4QAAAe8zAAANN9IAACmGFgARGblBAACeOEUAAh0t3wAAvQuoAAI+ma0AANkf5Q Date: Fri, 5 May 2017 16:06:03 +0000 Message-ID: <7236196A5DF6C040855A6D96F556A53F57B45F@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> <7236196A5DF6C040855A6D96F556A53F576D79@msmail.insydesw.com.tw> <0C09AFA07DD0434D9E2A0C6AEB0483103B87FD84@shsmsx102.ccr.corp.intel.com> <7236196A5DF6C040855A6D96F556A53F57707E@msmail.insydesw.com.tw>, <0C09AFA07DD0434D9E2A0C6AEB0483103B87FE7A@shsmsx102.ccr.corp.intel.com> <7236196A5DF6C040855A6D96F556A53F5770FA@msmail.insydesw.com.tw> <0C09AFA07DD0434D9E2A0C6AEB0483103B882229@shsmsx102.ccr.corp.intel.com> <7236196A5DF6C040855A6D96F556A53F578BB4@msmail.insydesw.com.tw> <0C09AFA07DD0434D9E2A0C6AEB0483103B8831C4@shsmsx102.ccr.corp.intel.com> <7236196A5DF6C040855A6D96F556A53F57AB2D@msmail.insydesw.com.tw> <0C09AFA07DD0434D9E2A0C6AEB0483103B883A7B@shsmsx102.ccr.corp.intel.com> In-Reply-To: <0C09AFA07DD0434D9E2A0C6AEB0483103B883A7B@shsmsx102.ccr.corp.intel.com> Accept-Language: en-US, zh-TW X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.100.109] 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: Fri, 05 May 2017 16:06:06 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Star, We would like to track the exact same defaulting as is used by PCDs. Otherw= ise it is confusing to users. If we were to say, "Use the this defaulting s= cheme for PCDs, but ignore it for all of the other runtime resource selecti= on." That would be confusing to users. Of course, we can decide not to use = this, but we actually like it. Tim -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Zeng= , Star Sent: Friday, May 05, 2017 3:08 AM To: Tim Lewis ; Kinney, Michael D ; edk2-devel@lists.01.org Cc: Zeng, Star ; Gao, Liming Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance Tim, In your code base, there are other tools beyond BaseTools to parse the [Sku= Ids] section and SKUID_IDENTIFIER in DSC, right? The boot time usage (use the value in DEFAULT SKU instead if the value in s= pecified SKU is not configured) for other resources in your code base is si= milar to PCD, right? This RFC has no change to this boot time behavior that "use the value in DE= FAULT SKU instead if the value in specified SKU is not configured". So I am still not so clear about the benefit of the macro like #define SKUI= D_IDENTIFIER_DEFAULT 2,1,0,1,0,0. The DSC syntax extension in this RFC is OPTIONAL, the backward compatibilit= y is expected to be kept, no current tools and code should be impacted. As I know, there will be a staging branch proposed for the development of P= CD related RFCs (include Structure PCD, etc). Mike and Liming can help conf= irm it. How about we have the development of this RFC to the staging branch first, = then you can help evaluate the syntax and provide feedback further? :) Thanks, Star -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Tim = Lewis Sent: Friday, May 5, 2017 12:36 AM To: Zeng, Star ; Kinney, Michael D ; edk2-devel@lists.01.org Cc: Gao, Liming Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance Star -- I understand your use case. We use the same behavior for other resources be= sides PCD.=20 All we are asking is that this data that is used by the build tools is also= available in some form at runtime.=20 Thanks, Tim =20 -----Original Message----- From: Zeng, Star [mailto:star.zeng@intel.com] Sent: Thursday, May 04, 2017 6:42 AM To: Tim Lewis ; Kinney, Michael D ; edk2-devel@lists.01.org Cc: Gao, Liming ; Zeng, Star Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance Tim, To avoid misunderstanding, I think I need to clarify more about this RFC. := ) This RFC is NOT to propose building real relationship (like parent-child) b= etween non-DEFAULT SKUs, it seems easy to bring confusion from the proposed= syntax " SkuValue|SkuName[|ParentSkuName]", especially the word 'Parent', = sorry for any confusion. The syntax extension proposed by this RFC is just to simplify the PCDs conf= iguring for multiple SKUs in DSC, I want to emphasize it is in DSC, it is t= o cover the case that some non-DEFAULT SKU has much PCD values equal with a= nother non-DEFAULT SKU, but less PCD values equal with DEFAULT SKU. This RFC has no any change to boot time behavior and does not break the rul= e that DEFAULT SKU PCD value will be returned if the specified SKU PCD valu= e is not configured in DSC, the code logic is below. PcdPeim Service.c: // // Find the current system's SKU ID entry in SKU ID table. // FoundSku =3D FALSE; for (Index =3D 0; Index < SkuIdTable[0]; Index++) { if (PeiPcdDb->SystemSkuId =3D=3D SkuIdTable[Index + 1]) { FoundSku =3D TRUE; break; } } // // Find the default SKU ID entry in SKU ID table. // if(!FoundSku) { for (Index =3D 0; Index < SkuIdTable[0]; Index++) { if (0 =3D=3D SkuIdTable[Index + 1]) { break; } } } The usage case you provided for other resources beyond PCD could be like be= low? CurrentSkuId =3D PcdGetSkuId(); Resource =3D NULL; if (!GetResourceForSkuId(CurrentSkuId, &Resource) { // try DEFAULT SKU GetResourceForSkuId(0, &Resource); } If (Resource =3D=3D NULL) { // error, no resource found for any of the SKU IDs } Thanks, Star -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Tim = Lewis Sent: Thursday, May 4, 2017 2:55 AM To: Zeng, Star ; Kinney, Michael D ; edk2-devel@lists.01.org Cc: Gao, Liming Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance We use SKU IDs for working with 15 different key resources in our product. = Some are related to code execution, but most are related to selection of re= sources. I mentioned logo components and HII strings already. I am asking that the information about SKU relationships be output in some = form so that it can be used at runtime, by whatever component. Today, there= is an implied relationship between a SKU X and the SKU DEFAULT for PCDs. W= e use this rule in many places, because it expresses a useful relationship. So, in the Project's .dsc file (forgive my syntax, which may not match your= s exactly) // Select which SKUs SKUID_IDENTIFIER =3D Sku2 Sku1 DEFAULT [SkuIds] 0|DEFAULT 1|Sku1 2|Sku2 Sku1 3|Sku3 In (proposed) AutoGen.h. This gives enough data for runtime usage. For othe= r build tools to use, maybe something else is required. // Output as an array initializer. DEFAULT is always last. // Only output for SKUs listed in SKUID_IDENTIFIER // 2->1->0 // 1->0 // 0 = #define SKUID_IDENTIFIER_DEFAULT 2,1,0,1,0,0 // In actual code: UINT32 SkuIdDefaults[] =3D {SKUID_IDENTIFIER_DEFAULT}; UINT32 *SkuId; UINT32 CurrentSkuId; BOOLEAN Found; VOID *Resource; CurrentSkuId =3D PcdGetSkuId(); SkuId =3D SkuIdDefaults; Found =3D (CurrentSkuId =3D=3D 0); // so that DEFAULT will also return TRUE= ; while (*SkuId !=3D 0) { if (*SkuId =3D=3D CurrentSkuId) { Found =3D TRUE; Break; } while (*SkuId !=3D 0) { SkuId++; } SkuId++; } if (!Found) { //error, because SKU ID was not found in array } Resource =3D NULL; while (!GetResourceForSkuId(*SkuId, &Resource) && *SkuId =3D=3D 0) { *SkuId++; } If (Resource =3D=3D NULL) { // error, no resource found for any of the SKU IDs } From: Zeng, Star [mailto:star.zeng@intel.com] Sent: Wednesday, May 03, 2017 7:03 AM To: Tim Lewis ; Kinney, Michael D ; edk2-devel@lists.01.org Cc: Gao, Liming ; Zeng, Star Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance Tim, Could you help share and explain the use cases in your code base that is us= ing [SkuIds] section and SKUID_IDENTIFIER for others beyond PCD? Then we can consider more in [RFC] PCD: Extended SKU support. Or do you hav= e detailed propose in this RFC or new RFC about your use cases? Thanks, Star From: Kinney, Michael D Sent: Friday, April 28, 2017 11:26 AM To: Tim Lewis >; Zeng, St= ar >; edk2-devel@lists.01.o= rg; Kinney, Michael D > Cc: Gao, Liming >; Zeng, = Star > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance Hi Star, The 2nd RFC for SKUs add some autogen to support setting the SKU from a pla= tform PEIM. We should consider additional autogen that allows a module to determine the= relationships between SKUs. This additional autogen is not required for t= he PCD part of the proposal, but could be used by other components. Mike From: Tim Lewis [mailto:tim.lewis@insyde.com] Sent: Thursday, April 27, 2017 7:09 PM To: Zeng, Star >; Kinney, M= ichael D >; e= dk2-devel@lists.01.org Cc: Gao, Liming >; Zeng, = Star > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance Start, The RFC adds a new mechanism for expressing a relationship between SKUs. Th= e [SkuIds] section is not tied to PCDs. The RFC wants to use this relationship to simplify PCD definitions in the D= SC file. Fine. But SkuId relationships are not exclusive to PCDs. There are= other places where such information can be used. Therefore, publishing thi= s information so that it can be used by other runtime agents besides the. P= CD driver makes sense. Many of these have nothing to do with EDK, but have = to do with OEM designs. Thanks, Tim Sent from my Windows 10 phone From: Zeng, Star Sent: Thursday, April 27, 2017 6:53 PM To: Tim Lewis; Kinney, Michael D; edk2-devel@lists.01.org Cc: Gao, Liming; Zeng, Star Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance Tim, So, you mean SKU in other scope? The title of this RFC is about PCD. Should they be discussed together? :) That relationship between PCD SKUs proposed by this RFC is just used to *si= mplify the PCDs configuring for multiple SKUs in DSC*. How the relationship between PCD SKUs impact other things? Thanks, Star -----Original Message----- From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Tim = Lewis Sent: Friday, April 28, 2017 9:43 AM To: Zeng, Star >; Kinney, M= ichael D >; e= dk2-devel@lists.01.org Cc: Gao, Liming > Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance Star -- Simply to say: We use SKUs for many more things than PCDs. While EDK2's bui= ld system may only use SKU IDs in relation with PCDs, our BIOS uses it for = many other things. So understanding the relationship between SKUs has an impact (for us) beyon= d what can be decided by the PCD database. Tim -----Original Message----- From: Zeng, Star [mailto:star.zeng@intel.com] Sent: Thursday, April 27, 2017 6:00 PM To: Tim Lewis >; Kinney, = Michael D >; = edk2-devel@lists.01.org Cc: Gao, Liming >; Zeng, = Star > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance Tim, Could you share more information about the case Hii string packages? Like Mike replied with below explanation, the purpose of this RFC is simple= to extend SKU inheritance in DSC. "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 d= atabase or behavior of PCD services." Thanks, Star -----Original Message----- From: Tim Lewis [mailto:tim.lewis@insyde.com] Sent: Friday, April 28, 2017 12:28 AM To: Kinney, Michael D >; Zeng, Star >; e= dk2-devel@lists.01.org Cc: Gao, Liming > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance Mike -- For the one-logo case, yes, that would work. But this is the simplest case.= Consider HII string packages. Tim -----Original Message----- From: Kinney, Michael D [mailto:michael.d.kinney@intel.com] Sent: Wednesday, April 26, 2017 5:28 PM To: Tim Lewis >; Zeng, St= ar >; edk2-devel@lists.01.o= rg; 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,=20 > Star >; > edk2-devel@lists.01.org > Cc: Gao, Liming > > Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance > > 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=20 > 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] > Sent: Wednesday, April 26, 2017 3:57 PM > To: Tim Lewis >; > Zeng, Star >; edk2-=20 > devel@lists.01.org; Kinney, Michael D=20 > > > 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=20 > could be used from the selected SKU? Maybe there is a different=20 > method to solve the 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=20 > relationships are not as straight forward when you add the concept of=20 > generating all possible combinations of SKUs from multiple subsystems. > > Thanks, > > Mike > > > -----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 >; > > 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 >; edk2-=20 > > 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 >; > > > 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 >; > > > edk2- devel@lists.01.org; Kinney,=20 > > > 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 >; > > > > 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-=20 > > > > 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 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, 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. > > > > > 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 > > > > > >; Gao, Liming=20 > > > > > > > > > > > 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] > > > > > 0 | DEFAULT > > > > > 1 | SkuA > > > > > 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 _______________________________________________ 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