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 7CD6121A134A6 for ; Mon, 15 May 2017 09:30:48 -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; Tue, 16 May 2017 00:30:45 +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+ma0AAM/SqgAeoHXDAADlUEcA== Date: Mon, 15 May 2017 16:30:44 +0000 Message-ID: <7236196A5DF6C040855A6D96F556A53F57E4C2@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> <0C09AFA07DD0434D9E2A0C6AEB0483103B8B3930@shsmsx102.ccr.corp.intel.com> In-Reply-To: <0C09AFA07DD0434D9E2A0C6AEB0483103B8B3930@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.111] 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: Mon, 15 May 2017 16:30:49 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Star -- Thanks for your work on this. I have reviewed this and it looks good, addre= ssing all of our concerns. Tim -----Original Message----- From: Zeng, Star [mailto:star.zeng@intel.com]=20 Sent: Monday, May 15, 2017 2:46 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 Thanks all for the comments to this RFC. I have sent out the V2 of this RFC at https://www.mail-archive.com/edk2-dev= el@lists.01.org/msg25687.html. Tim, Could you help review the V2 of this RFC and provide feedback? With the V2 of this RFC, the actual code for the runtime usage you provided= will be like below. UINT64 SkuId; VOID *Resource; SkuId =3D LibPcdGetSku (); Resource =3D NULL; while (!GetResourceForSkuId (SkuId, &Resource) && SkuId !=3D 0) { SkuId =3D PcdGetParentSkuId (SkuId); } If (Resource =3D=3D NULL) { // error, no resource found. } Thanks, Star -----Original Message----- From: Kinney, Michael D Sent: Saturday, May 6, 2017 12:07 AM To: Zeng, Star ; Tim Lewis ; edk= 2-devel@lists.01.org; Kinney, Michael D Cc: Gao, Liming Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance Star, I think Tim's feedback is a request for an additional feature on top of thi= s RFC. I do not see any requests for changes to the proposed syntax extens= ions. I agree that implementing these new feature in an edk2-staging branc= h makes a lot of sense. =20 Since Tim's request is about access to the SKU relationships from FW module= s when the FW module executes, let's discuss this from an API perspective i= nstead of detailed autogen. We can figure out what autogen is required to = support the API. When a platform boots with multiple SKUs enabled in the FW image, typically= a platform PEIM detects what SKU is present can calls the PcdLib function = LibPcdSetSku() to set the active SKU. Then, that same module or other modules may want to know how the current SK= U is related to other SKUs. Those other modules can start with LibPcdGetSk= u() to get the active SKU. This RFC introduces the concept that one SKU may be a derivative of another= SKU, and may be used to reduce the total number PCD statements in a DSC fi= le. This derivative concept can be thought of as parent to child link betw= een the 2 SKUs. We can draw this visually as a tree with parent child rela= tionships between all the SKUs. Now from a module that calls LibPcdGetSku(), the module may want to know wh= o the parent SKU is. The information we have about the parent SKU is the S= KU ID value. A new API that may be useful here is something like: UINTN GetParentSku ( IN UINTN SkuId ); The algorithm that Tim provided below uses autogen and a loop to retrieve t= he parent SKU. So the request here is to extend the autogen to support a lookup of the par= ent SKU given any valid SKU ID value. Thanks, Mike =20 > -----Original Message----- > From: Zeng, Star > Sent: Friday, May 5, 2017 3:08 AM > To: Tim Lewis ; Kinney, Michael D=20 > ; edk2-devel@lists.01.org > Cc: Gao, Liming ; Zeng, Star=20 > > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance >=20 > Tim, >=20 > In your code base, there are other tools beyond BaseTools to parse the=20 > [SkuIds] section and SKUID_IDENTIFIER in DSC, right? >=20 > The boot time usage (use the value in DEFAULT SKU instead if the value=20 > in specified SKU is not configured) for other resources in your code base= is similar to PCD, right? > This RFC has no change to this boot time behavior that "use the value=20 > in DEFAULT 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=20 > SKUID_IDENTIFIER_DEFAULT 2,1,0,1,0,0. >=20 >=20 > The DSC syntax extension in this RFC is OPTIONAL, the backward=20 > compatibility 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=20 > of PCD related RFCs (include Structure PCD, etc). Mike and Liming can hel= p confirm it. > How about we have the development of this RFC to the staging branch=20 > first, then you can help evaluate the syntax and provide feedback=20 > further? :) >=20 >=20 > Thanks, > Star > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of=20 > Tim Lewis > Sent: Friday, May 5, 2017 12:36 AM > To: Zeng, Star ; Kinney, Michael D=20 > ; edk2-devel@lists.01.org > Cc: Gao, Liming > Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance >=20 > Star -- >=20 > I understand your use case. We use the same behavior for other resources = besides PCD. >=20 > All we are asking is that this data that is used by the build tools is=20 > also available in some form at runtime. >=20 > Thanks, >=20 > Tim >=20 >=20 >=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=20 > ; edk2-devel@lists.01.org > Cc: Gao, Liming ; Zeng, Star=20 > > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance >=20 > Tim, >=20 > To avoid misunderstanding, I think I need to clarify more about this=20 > RFC. :) >=20 > This RFC is NOT to propose building real relationship (like > parent-child) between non- DEFAULT SKUs, it seems easy to bring confusion= from the proposed syntax " > SkuValue|SkuName[|ParentSkuName]", especially the word 'Parent', sorry=20 > SkuValue|for any > confusion. > The syntax extension proposed by this RFC is just to simplify the PCDs=20 > configuring for multiple SKUs in DSC, I want to emphasize it is in=20 > DSC, it is to cover the case that some non-DEFAULT SKU has much PCD=20 > values equal with another 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=20 > the rule that DEFAULT SKU PCD value will be returned if the specified=20 > SKU PCD value is not configured in DSC, the code logic is below. >=20 > 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; > } > } >=20 > // > // 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; > } > } > } >=20 >=20 > The usage case you provided for other resources beyond PCD could be like = below? >=20 > CurrentSkuId =3D PcdGetSkuId(); >=20 > 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 } >=20 >=20 >=20 > Thanks, > Star > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of=20 > Tim Lewis > Sent: Thursday, May 4, 2017 2:55 AM > To: Zeng, Star ; Kinney, Michael D=20 > ; edk2-devel@lists.01.org > Cc: Gao, Liming > Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance >=20 > We use SKU IDs for working with 15 different key resources in our=20 > product. Some are related to code execution, but most are related to=20 > selection of resources. I mentioned logo components and HII strings alrea= dy. >=20 > I am asking that the information about SKU relationships be output in=20 > 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=20 > DEFAULT for PCDs. We use this rule in many places, because it expresses a= useful relationship. >=20 > So, in the Project's .dsc file (forgive my syntax, which may not match=20 > yours exactly) >=20 > // Select which SKUs > SKUID_IDENTIFIER =3D Sku2 Sku1 DEFAULT >=20 > [SkuIds] > 0|DEFAULT > 1|Sku1 > 2|Sku2 Sku1 > 3|Sku3 >=20 > In (proposed) AutoGen.h. This gives enough data for runtime usage. For=20 > other build tools to use, maybe something else is required. >=20 > // Output as an array initializer. DEFAULT is always last. > // Only output for SKUs listed in SKUID_IDENTIFIER // 2->1->0 // 1->0=20 > // 0 #define SKUID_IDENTIFIER_DEFAULT 2,1,0,1,0,0 >=20 > // In actual code: >=20 > UINT32 SkuIdDefaults[] =3D {SKUID_IDENTIFIER_DEFAULT}; > UINT32 *SkuId; > UINT32 CurrentSkuId; > BOOLEAN Found; > VOID *Resource; >=20 > CurrentSkuId =3D PcdGetSkuId(); >=20 > SkuId =3D SkuIdDefaults; > Found =3D (CurrentSkuId =3D=3D 0); // so that DEFAULT will also return TR= UE;=20 > 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 } >=20 > 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 } >=20 >=20 >=20 >=20 >=20 >=20 > From: Zeng, Star [mailto:star.zeng@intel.com] > Sent: Wednesday, May 03, 2017 7:03 AM > To: Tim Lewis ; Kinney, Michael D=20 > ; edk2-devel@lists.01.org > Cc: Gao, Liming ; Zeng, Star=20 > > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance >=20 > Tim, >=20 > Could you help share and explain the use cases in your code base that=20 > is using [SkuIds] section and SKUID_IDENTIFIER for others beyond PCD? > Then we can consider more in [RFC] PCD: Extended SKU support. Or do=20 > you have detailed propose in this RFC or new RFC about your use cases? >=20 > Thanks, > Star > From: Kinney, Michael D > Sent: Friday, April 28, 2017 11:26 AM > To: Tim Lewis >; > Zeng, Star >; edk2-=20 > devel@lists.01.org; Kinney, Michael D=20 > > > Cc: Gao, Liming >; > Zeng, Star > > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance >=20 > Hi Star, >=20 > The 2nd RFC for SKUs add some autogen to support setting the SKU from a p= latform PEIM. >=20 > We should consider additional autogen that allows a module to=20 > determine the relationships between SKUs. This additional autogen is=20 > not required for the PCD part of the proposal, but could be used by other= components. >=20 > Mike >=20 > From: Tim Lewis [mailto:tim.lewis@insyde.com] > Sent: Thursday, April 27, 2017 7:09 PM > To: Zeng, Star >; > Kinney, Michael D > >; edk2-=20 > devel@lists.01.org > Cc: Gao, Liming >; > Zeng, Star > > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance >=20 >=20 > Start, >=20 >=20 >=20 > The RFC adds a new mechanism for expressing a relationship between=20 > SKUs. The [SkuIds] section is not tied to PCDs. >=20 >=20 >=20 > The RFC wants to use this relationship to simplify PCD definitions in the= DSC file. > Fine. But SkuId relationships are not exclusive to PCDs. There are=20 > other places where such information can be used. Therefore, publishing=20 > this information so that it can be used by other runtime agents=20 > besides the. PCD driver makes sense. Many of these have nothing to do wit= h EDK, but have to do with OEM designs. >=20 >=20 >=20 > Thanks, >=20 >=20 >=20 > Tim >=20 >=20 >=20 > Sent from my Windows 10 phone >=20 >=20 >=20 > From: Zeng, Star > Sent: Thursday, April 27, 2017 6:53 PM > To: Tim Lewis; Kinney, Michael=20 > D;=20 > edk2-devel@lists.01.org devel@lists.01.org> > Cc: Gao, Liming; Zeng,=20 > Star > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance >=20 >=20 > Tim, >=20 > So, you mean SKU in other scope? >=20 > The title of this RFC is about PCD. Should they be discussed together?=20 > :) >=20 > That relationship between PCD SKUs proposed by this RFC is just used=20 > to *simplify the PCDs configuring for multiple SKUs in DSC*. > How the relationship between PCD SKUs impact other things? >=20 >=20 > Thanks, > Star > -----Original Message----- > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of=20 > Tim Lewis > Sent: Friday, April 28, 2017 9:43 AM > To: Zeng, Star >;=20 > Kinney, Michael D=20 > >; edk2-=20 > devel@lists.01.org > Cc: Gao, Liming > > Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance >=20 > Star -- >=20 > Simply to say: We use SKUs for many more things than PCDs. While=20 > EDK2's build system may only use SKU IDs in relation with PCDs, our BIOS = uses it for many other things. >=20 > So understanding the relationship between SKUs has an impact (for us)=20 > beyond what can be decided by the PCD database. >=20 > Tim >=20 > -----Original Message----- > From: Zeng, Star [mailto:star.zeng@intel.com] > Sent: Thursday, April 27, 2017 6:00 PM > To: Tim Lewis >;=20 > Kinney, Michael D=20 > >; edk2-=20 > devel@lists.01.org > Cc: Gao, Liming >;=20 > Zeng, Star > > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance >=20 > Tim, >=20 > Could you share more information about the case Hii string packages? >=20 > Like Mike replied with below explanation, the purpose of this RFC is=20 > simple to extend SKU inheritance in DSC. >=20 > "With this proposal, a relationship between SKUs can be declared in=20 > the 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 > Thanks, > Star > -----Original Message----- > From: Tim Lewis [mailto:tim.lewis@insyde.com] > Sent: Friday, April 28, 2017 12:28 AM > To: Kinney, Michael D=20 > >; > Zeng, Star >; edk2-=20 > devel@lists.01.org > Cc: Gao, Liming > > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance >=20 > Mike -- >=20 > For the one-logo case, yes, that would work. But this is the simplest=20 > case. Consider HII string packages. >=20 > Tim >=20 > -----Original Message----- > From: Kinney, Michael D [mailto:michael.d.kinney@intel.com] > Sent: Wednesday, April 26, 2017 5:28 PM > To: Tim Lewis >;=20 > Zeng, Star >; edk2-=20 > devel@lists.01.org; Kinney, Michael D=20 > > > Cc: Gao, Liming > > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance >=20 > Tim, >=20 > Could you use a PCD (for example a GUID value of an FFS file) for the=20 > Logo, and you could use PcdGet() after SetSku() and the GUID value of=20 > the FFS file with the logo would be returned for the lookup. >=20 > That way, the need for the relationship information at runtime is=20 > removed and you would get the behavior you describe below. >=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 4:06 PM > > To: Kinney, Michael D > > >;=20 > > Zeng, 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=20 > > of generating all possible combinations of SKUs from multiple subsystem= s. > > > > 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 12:59 PM > > > To: Kinney, Michael D > > > >; > > > Zeng, Star >; > > > edk2-devel@lists.01.org > > > Cc: Gao, Liming=20 > > > > > > > Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 -=20 > > > 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 initializ= er: > > > > > > #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=20 > > > are 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=20 > > > all 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=20 > > > was built for A,B,C and the SKU detected during POST was D. By=20 > > > having a macro that returns whether board X is supported, code=20 > > > which is not used for the current build can be eliminated from the=20 > > > build. For 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=20 > > > command-line to allow multiple instances of -x to correctly populate = the SKUID_IDENTIFIER. > > > > > > 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,=20 > > > Michael D=20 > > > > > > > Cc: Gao, Liming=20 > > > > > > > Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance > > > > > > Hi Tim, > > > > > > If multiple SKUs are present in a FW image, in most cases A=20 > > > platform specific PEIM detects what SKU is present and calls=20 > > > SetSku() for the detected SKU. The detection mechanism is=20 > > > typically very HW specific and may involve checking straps, GPIOs, or= reading ID values from registers. > > > > > > 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=20 > > > SKU 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=20 > > > > cannot 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=20 > > > > >; > > > > 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=20 > > > > some 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=20 > > > > an 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=20 > > > > more optimal ways to store the data and more efficient ways to=20 > > > > access the data. But we would like to consider any work in this=20 > > > > area as a separate work item. Please feel free to add a=20 > > > > Bugzilla feature request if you have specific ideas on how to=20 > > > > reduce size and/or improve > > > performance. > > > > > > > > Given that this RFC is only about a more efficient DSC file impleme= ntation. > > > > 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=20 > > > > > us) 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=20 > > > > > differences between SKU A/SKU B and SKU DEFAULT must exist in=20 > > > > > the PCD database (SKU A and SKU B are sparsely encoded). Are=20 > > > > > you saying that this proposed change will not, in fact,=20 > > > > > 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. > > > > > > > > > > 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,=20 > > > > > Star >; edk2-=20 > > > > > devel@lists.01.org; Kinney, Michael=20 > > > > > 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=20 > > > > > provide PCD values for different SKUs with fewer PCD statements i= n 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=20 > > > > > SKU specific PCD statement > > > > is required. > > > > > > > > > > With this proposal, a relationship between SKUs can be=20 > > > > > declared in the DSC file, so SKUs can inherit PCD values from oth= er SKUs. > > > > > This inheritance is limited to the scope of the DSC file. =20 > > > > > This RFC has no impact to the PCD database or behavior of PCD ser= vices. > > > > > > > > > > The example Star provides at the end shows the equivalent set=20 > > > > > of PCD settings using the current EDK II syntax and with this=20 > > > > > RFC's 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= syntax. > > > > > In fact, that is what the implementation of this RFC would do=20 > > > > > to 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 > > > > > > > > > > > m> > > > > > > >; 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,=20 > > > > > > and 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 availabl= e externally. > > > > > > 2) There is no way to read the contents of SKUID_IDENTIFIER=20 > > > > > > when multiple SKUs are specified. While more than one SKU=20 > > > > > > can be specified (separated by spaces), there is no way to=20 > > > > > > pass multiple values into build.exe today, nor is there any=20 > > > > > > way to identify which SKUs (out of the total list of SKUs)=20 > > > > > > is 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 > > > > > > > > > > > m> > > > > > > >; Zeng, Star > > > > > > >; Gao,=20 > > > > > > 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=20 > > > > > > could 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=20 > > > > > > the extension is optional. > > > > > > This proposal keeps the backward compatibility with current SKU= usage. > > > > > > 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=20 > > > > > > in this proposal and defines which SKU the PCD value will=20 > > > > > > derive from for this SKU. The PCD value will derive from=20 > > > > > > DEFAULT SKU for this SKU if the > > > > > ParentSkuName is absent. > > > > > > > > > > > > > > > > > > - Example: SkuB is a derivative of SkuA, but not a derivative o= f 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