From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 96E3421954068 for ; Thu, 27 Apr 2017 19:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1493344956; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5EDLMr1DF/btgLLHgMUAIUsVkJROCVKxqVW3BxrXwS0=; b=tAgqv5eifY6Hbo4KIsbucZ4sa32agNuqP0s/gqymhV19OjEnOD+YfC1W6uZsyXvk yXfA5l24sJUMFllTz5KlsMHgzbBY/cjNaArA7QgWB97qwsXIim8wHClHHKSwoW7+ IIWPrJKqabospJ6QBojU5Prpx1YDlnMi0Na1PjeUKN/zD9MMYHjQNzcVHYZHjixl IH95J1DM61RlwCz3NDuXh5vAIdvn3iq9pIm6vdpSB8dZHzJw2yQSi46QuLDlEOum Ux5yXaSGk7hNXIjUxFeeCuPtNJmetc6BcQzLgzKfFNxMybai9aH8PbZqglYrmEGy vE3h19Fjq6TXY4CX77pqCg==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id A6.7E.02615.BB2A2095; Thu, 27 Apr 2017 19:02:36 -0700 (PDT) X-AuditID: 11ab0216-1a3fc9a000000a37-30-5902a2bb6451 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by relay3.apple.com (Apple SCV relay) with SMTP id F1.6F.15148.BB2A2095; Thu, 27 Apr 2017 19:02:35 -0700 (PDT) MIME-version: 1.0 Received: from [17.153.32.7] (unknown [17.153.32.7]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OP3003DKKC9PM20@nwk-mmpp-sz13.apple.com>; Thu, 27 Apr 2017 19:02:35 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish In-reply-to: <0C09AFA07DD0434D9E2A0C6AEB0483103B87FE7A@shsmsx102.ccr.corp.intel.com> Date: Thu, 27 Apr 2017 19:02:33 -0700 Cc: Tim Lewis , Mike Kinney , "edk2-devel@lists.01.org" , "Gao, Liming" Message-id: <29F15248-7AFB-406B-A2A0-4C220521C7F6@apple.com> 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> To: "Zeng, Star" X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUi2FAYrLtnEVOkwfcdyhZ7Dh1ltlhxbwO7 RUfHPyaLfb3WFhd/rGJyYPVof/OfzWPxnpdMHt2z/7EEMEdx2aSk5mSWpRbp2yVwZbR+2M9S cGAJY8XThf8YGxhPtzJ2MXJySAiYSEz4epcNxBYSWMMkcWqNI0z8yZLl7F2MXEDxQ4wSj098 ZwJJ8AoISvyYfI+li5GDg1lAXuLgeVmQMLOAlsT3R60sEHO6mSTW7xQAsYUFxCXendnEDGE7 S3zpXcEOYrMJKEusmP8BzOYUCJOYePwIE8hIFgFVielXzEHWMgusZZTYNX8JC8RaG4l9088y Q9yzkkPi3MJTrCAJEQE1ib2rd7FDHC0rcWv2JbAiCYEzbBJtsx+yTWAUnoXk7lkId89CcvcC RuZVjMK5iZk5upl5RkZ6iQUFOal6yfm5mxhBUbCaSWwH473XhocYBTgYlXh4Iz4xRgqxJpYV V+YeYpTmYFES563LYooUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwNgtoeh5ZXLghIUiHPa5 JaFueXZOy6dvYmyQmSMg3y8tvrAh+EOxl/PCg0vLLvtVftwW+pk3rjRg0tTqLPaFp+9N1A+t y2q+wnaYM+jFBa85sRbn++q/ab7aHP5r27HP+lucmpbOmhrz46LpKhu3FfmpQT+uv9Dc8kZM SGpGwoEXK77zOzhMj1BiKc5INNRiLipOBACPf2aPYwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUi2FB8Q3f3IqZIg+8/tSz2HDrKbLHi3gZ2 i46Of0wW+3qtLS7+WMXkwOrR/uY/m8fiPS+ZPLpn/2MJYI7isklJzcksSy3St0vgymj9sJ+l 4MASxoqnC/8xNjCebmXsYuTkkBAwkXiyZDl7FyMXh5DAIUaJxye+M4EkeAUEJX5MvsfSxcjB wSwgL3HwvCxImFlAS+L7o1YWEFtIoJtJYv1OARBbWEBc4t2ZTcwQtrPEl94V7CA2m4CyxIr5 H8BsToEwiYnHjzCBjGQRUJWYfsUcZC2zwFpGiV3zl7BArLWR2Df9LDPEPSs5JM4tPMUKkhAR UJPYu3oXO8TRshK3Zl9insAoMAvJqbMQTp2F5NQFjMyrGAWKUnMSK431EgsKclL1kvNzNzGC g7YweAfjn2VWhxgFOBiVeHgZPjBGCrEmlhVX5gLDgoNZSYRXMpEpUog3JbGyKrUoP76oNCe1 +BBjFdADE5mlRJPzgRGVVxJvaGJiYGJsbGZsbG5iThVhJXHeadlAmwXSE0tSs1NTC1KLYJYz cXBKNTD67Jz3vpqleM7erZ2pOh2+DRaRjxc2+/y5bPeZof3mJWEzjlXpSRfKZ3u/XsH9bfoO lfvCWWz8O03fBEf0O+kdf1xpW8X1PJpRh6WnV99r8Zxd3FI2y2fFVUV1bhY6Xfdrk9fJx31J z4K4X4uHP4w21FxT+b9Z64jQrOJsX4Y9dz5YnRW5dEOJpTgj0VCLuag4EQDPzh6gtQIAAA== 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, 28 Apr 2017 02:02:37 -0000 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII > On Apr 27, 2017, at 6:53 PM, Zeng, Star wrote: > > 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 *simplify the PCDs configuring for multiple SKUs in DSC*. > How the relationship between PCD SKUs impact other things? > Star, It seems to me the SKU implies what data you get from a PCD, but there may be code paths that need to be different per SKU. Does the current proposal support this, or does there need to a manual feature flag/PCD value for code that needs to kept in sync with the SKU value? I guess you could use the SKU support to manually make a PCD that tracks the SKU for code paths, but that seems a little redundant? Why would the build system not just automate this? Thanks, Andrew Fish > > 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, Michael D ; edk2-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 build 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) beyond 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 database 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 ; edk2-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, Star ; edk2-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 file with the logo would be returned for the lookup. > > That way, the need for the relationship information at runtime is removed and you would get the behavior you describe below. > > Mike > >> -----Original Message----- >> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of >> Tim Lewis >> Sent: Wednesday, April 26, 2017 4:06 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 -- >> >> 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] >> Sent: Wednesday, April 26, 2017 3:57 PM >> To: Tim Lewis ; Zeng, Star >> ; edk2- 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 be used from the selected SKU? Maybe there is a different >> 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 >> relationships are not as straight forward when you add the concept of >> 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 >>> 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 >>> 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 >>> 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 >>> possible set of SKU A-H), but the SKU detected is: G. This is an >>> error condition that is difficult to detect. SetSku() can't do it, >>> because there is no guarantee (today) that the PCD driver knows 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 was >>> built for A,B,C and the SKU detected during POST was D. By having a >>> macro that returns whether board X is supported, code which is not >>> used for the current build can be eliminated from the build. For >>> example. #define SKU_NAME_SUPPORTED(sku- >>> identifier) can return FALSE if the SKU associated with >>> 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 >>> 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 >>> ; edk2- devel@lists.01.org; Kinney, Michael D >>> >>> 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 >>> specific PEIM detects what SKU is present and calls SetSku() for the >>> detected SKU. The detection mechanism is 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 >>> SKU (SKU ID 0). After SetSku() is called, the PCD services access >>> values for that specific SKU. >>> >>> What would be the runtime use case for being able to lookup the >>> relationships between SKUs if in a single boot only the DEFAULT SKU >>> and the one SKU passed to >>> SetSku() are involved? >>> >>> What additions do you suggest to this RFC or to another RFC that >>> builds on top of this RFC? >>> >>> Thanks, >>> >>> Mike >>> >>>> -----Original Message----- >>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On >>>> 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 - >>>> inheritance >>>> >>>> Mike -- >>>> >>>> I am saying that creating a relationship between SKUs that 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 ; Zeng, Star >>>> ; edk2- devel@lists.01.org; Kinney, Michael D >>>> >>>> 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 >>>> 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 >>>> clarifications for the next revision of this RFC. >>>> >>>> This RFC is about reducing the number of PCD statements in a DSC >>>> file if there are multiple SKUs and if there is a relationship >>>> between SKUs that can be used to support that reduction. It is an >>>> optional new feature. You do not have to use it. >>>> >>>> I consider the optimization of the PCD database from a size and >>>> performance perspective a separate topic. The implementation of >>>> this RFC does not require any changes to the PCD database format >>>> or the way PCD value lookup algorithm in the PCD drivers. >>>> >>>> We do recognize that if a large number of SKUs with close >>>> relationships are present in a single FW build, there may be more >>>> optimal ways to store the data and more efficient ways to access >>>> the data. But we would like to consider any work in this area as >>>> a separate work item. Please feel free to add a Bugzilla feature >>>> request if you have specific ideas on how to reduce size and/or >>>> improve >>> performance. >>>> >>>> Given that this RFC is only about a more efficient DSC file implementation. >>>> Can you please describe your concerns with SKUs as they are >>>> currently documented in the EDK II specifications? If you have >>>> additional feature requests for the EDK II SKU behavior, then I >>>> look forward to seeing >>> your detailed proposals. >>>> >>>> Thanks, >>>> >>>> Mike >>>> >>>>> -----Original Message----- >>>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On >>>>> 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 - >>>>> inheritance >>>>> >>>>> I understand the purpose. Today there is an assumption that IF >>>>> not SKU x, then use SKU DEFAULT. This assumption is used (by us) >>>>> for many purposes other than the PCD database. >>>>> >>>>> I'm confused by your statement that "This RFC has no impact to >>>>> the PCD database or behavior of PCD services." Currently, as I >>>>> recall, there is an optimization that says: only the differences >>>>> between SKU A/SKU B and SKU DEFAULT must exist in the PCD >>>>> database (SKU A and SKU B are sparsely encoded). Are you saying >>>>> that this proposed change will not, in fact, optimize the PCD >>>>> database for SKU B (that it will have the full set of values >>>>> that differ from SKU >>>>> DEFAULT?) If so, it >>> is a pity. >>>>> >>>>> My other concern is that, we use the defaulting assumption for >>>>> many other >>>> items. >>>>> For example: logos. Leaving it as a build-time construct only >>>>> prevents other components from taking advantage of this knowledge. >>>>> >>>>> Tim >>>>> >>>>> On a separate, but related topic, the term "SKU" has a broad >>>>> connotation, and we use it for many other items board-specific >>>>> at build-time >>>> and run-time (ie. >>>>> Logos). Leaving the defaulting relationship as a build-time >>>>> construct prevents usage at runtime. This is similar run-time >>>>> problem to the case when (a) there are >>>>> 10 SKUs listed in [SkuIds] but (b) 3 are listed in >>>>> SKUID_IDENTIFIERS for this particular build. How, at runtime, >>>>> does C code pick up that SkuA is supported in the current build? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Kinney, Michael D [mailto:michael.d.kinney@intel.com] >>>>> Sent: Wednesday, April 26, 2017 11:05 AM >>>>> To: Tim Lewis ; Zeng, Star >>>>> ; edk2- devel@lists.01.org; Kinney, Michael >>>>> D >>>>> Cc: Gao, Liming >>>>> Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance >>>>> >>>>> Tim, >>>>> >>>>> Can you please provide more details on your specific concerns >>>>> along with some use cases? >>>>> >>>>> This RFC does not change the SKU feature in EDK II. This RFC >>>>> simply provides a more efficient way for a developer to provide >>>>> PCD values for different SKUs with fewer PCD statements in a DSC file. >>>>> >>>>> Today, every SKU is a based on the DEFAULT SKU and if a PCD >>>>> requires a different value than the DEFAULT SKU value, then a >>>>> SKU specific PCD statement >>>> is required. >>>>> >>>>> 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 database or behavior of PCD services. >>>>> >>>>> The example Star provides at the end shows the equivalent set of >>>>> PCD settings using the current EDK II syntax and with this RFC's >>>>> backwards compatible syntax extensions. >>>>> >>>>> One way to think about this RFC is that a DSC file using the >>>>> syntax in this RFC can be converted to a DSC file without the RFC syntax. >>>>> In fact, that is what the implementation of this RFC would do to >>>>> build the set of >>>> PCD values for each SKU. >>>>> >>>>> Thanks, >>>>> >>>>> Mike >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On >>>>>> 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 - >>>>>> inheritance >>>>>> >>>>>> Star -- >>>>>> >>>>>> This assumes that the SKU ID is only used for PCDs, which is >>>>>> not the case. The SKU ID may be used by other components, 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 available externally. >>>>>> 2) There is no way to read the contents of SKUID_IDENTIFIER >>>>>> when multiple SKUs are specified. While more than one SKU can >>>>>> be specified (separated by spaces), there is no way to pass >>>>>> multiple values into build.exe today, nor is there any way to >>>>>> identify which SKUs (out of the total list of SKUs) is >>>>>> supported on one build at >>> runtime. >>>>>> >>>>>> Tim >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On >>>>>> 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 >>>>>> 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 >>>>>> not derive from another non-DEFAULT SKU. >>>>>> For example below, SkuA and SkuB could only derive from >>>>>> 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 >>>>>> another non-DEFAULT >>>>> SKU. >>>>>> This proposal only extends DSC [SkuIds] section syntax and the >>>>>> extension is optional. >>>>>> This proposal keeps the backward compatibility with current SKU usage. >>>>>> BaseTools update is needed to support the syntax extension, >>>>>> and no any 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 >>>>>> this proposal and defines which SKU the PCD value will derive >>>>>> from for this SKU. The PCD value will derive from DEFAULT SKU >>>>>> 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 >>>>>> derive from DEFAULT SKU and be FLASE. >>>>>> >>>>>> [PcdsDynamicDefault.Common.SkuB] >>>>>> gXXXPkgTokenSpaceGuid.PcdXXXSignature|" SkuB" >>>>>> # No need statement for PcdXXXConfig1 and PcdXXXConfig2 >>>>>> 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