[RFC] PCD: Extended SKU support 1 - inheritance

[RFC] PCD: Extended SKU support 1 - inheritance

[Zeng, Star]

- 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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

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 <michael.d.kinney@intel.com>; Zeng, Star <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>
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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Kinney, Michael D]

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 <star.zeng@intel.com>; edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming
> <liming.gao@intel.com>
> 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 <michael.d.kinney@intel.com>; Zeng, Star
> <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>
> 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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

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 <tim.lewis@insyde.com>; Zeng, Star <star.zeng@intel.com>; edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Gao, Liming <liming.gao@intel.com>
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 <star.zeng@intel.com>; edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming 
> <liming.gao@intel.com>
> 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 <michael.d.kinney@intel.com>; Zeng, Star 
> <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>
> 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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Kinney, Michael D]

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 <michael.d.kinney@intel.com>; Zeng, Star
> <star.zeng@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <tim.lewis@insyde.com>; Zeng, Star <star.zeng@intel.com>; edk2-
> devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <star.zeng@intel.com>; edk2-devel@lists.01.org
> > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming
> > <liming.gao@intel.com>
> > 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 <michael.d.kinney@intel.com>; Zeng, Star
> > <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>
> > 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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

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 <tim.lewis@insyde.com>; Zeng, Star <star.zeng@intel.com>; edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Gao, Liming <liming.gao@intel.com>
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 <michael.d.kinney@intel.com>; Zeng, Star 
> <star.zeng@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <tim.lewis@insyde.com>; Zeng, Star 
> <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
> <michael.d.kinney@intel.com>
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <star.zeng@intel.com>; edk2-devel@lists.01.org
> > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming 
> > <liming.gao@intel.com>
> > 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>
> > 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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Kinney, Michael D]

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 <michael.d.kinney@intel.com>; Zeng, Star
> <star.zeng@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <tim.lewis@insyde.com>; Zeng, Star <star.zeng@intel.com>; edk2-
> devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <michael.d.kinney@intel.com>; Zeng, Star
> > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > Cc: Gao, Liming <liming.gao@intel.com>
> > 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 <tim.lewis@insyde.com>; Zeng, Star
> > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D
> > <michael.d.kinney@intel.com>
> > Cc: Gao, Liming <liming.gao@intel.com>
> > 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 <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming
> > > <liming.gao@intel.com>
> > > 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 <michael.d.kinney@intel.com>; Zeng, Star
> > > <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>
> > > 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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

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 <tim.lewis@insyde.com>; Zeng, Star <star.zeng@intel.com>; edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Gao, Liming <liming.gao@intel.com>
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 <michael.d.kinney@intel.com>; Zeng, Star 
> <star.zeng@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <tim.lewis@insyde.com>; Zeng, Star 
> <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
> <michael.d.kinney@intel.com>
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > Cc: Gao, Liming <liming.gao@intel.com>
> > 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 <tim.lewis@insyde.com>; Zeng, Star 
> > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
> > <michael.d.kinney@intel.com>
> > Cc: Gao, Liming <liming.gao@intel.com>
> > 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 <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming 
> > > <liming.gao@intel.com>
> > > 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > > <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>
> > > 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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Kinney, Michael D]

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 <michael.d.kinney@intel.com>; Zeng, Star
> <star.zeng@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <tim.lewis@insyde.com>; Zeng, Star <star.zeng@intel.com>; edk2-
> devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <michael.d.kinney@intel.com>; Zeng, Star
> > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > Cc: Gao, Liming <liming.gao@intel.com>
> > 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 <tim.lewis@insyde.com>; Zeng, Star
> > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D
> > <michael.d.kinney@intel.com>
> > Cc: Gao, Liming <liming.gao@intel.com>
> > 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 <michael.d.kinney@intel.com>; Zeng, Star
> > > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > Cc: Gao, Liming <liming.gao@intel.com>
> > > 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 <tim.lewis@insyde.com>; Zeng, Star
> > > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D
> > > <michael.d.kinney@intel.com>
> > > Cc: Gao, Liming <liming.gao@intel.com>
> > > 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 <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming
> > > > <liming.gao@intel.com>
> > > > 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 <michael.d.kinney@intel.com>; Zeng, Star
> > > > <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>
> > > > 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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

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 <tim.lewis@insyde.com>; Zeng, Star <star.zeng@intel.com>; edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Gao, Liming <liming.gao@intel.com>
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 <michael.d.kinney@intel.com>; Zeng, Star 
> <star.zeng@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <tim.lewis@insyde.com>; Zeng, Star 
> <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
> <michael.d.kinney@intel.com>
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > Cc: Gao, Liming <liming.gao@intel.com>
> > 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 <tim.lewis@insyde.com>; Zeng, Star 
> > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
> > <michael.d.kinney@intel.com>
> > Cc: Gao, Liming <liming.gao@intel.com>
> > 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > Cc: Gao, Liming <liming.gao@intel.com>
> > > 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 <tim.lewis@insyde.com>; Zeng, Star 
> > > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
> > > <michael.d.kinney@intel.com>
> > > Cc: Gao, Liming <liming.gao@intel.com>
> > > 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 <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming 
> > > > <liming.gao@intel.com>
> > > > 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > > > <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>
> > > > 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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Kinney, Michael D]

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 <michael.d.kinney@intel.com>; Zeng, Star
> <star.zeng@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <tim.lewis@insyde.com>; Zeng, Star <star.zeng@intel.com>; edk2-
> devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <michael.d.kinney@intel.com>; Zeng, Star
> > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > Cc: Gao, Liming <liming.gao@intel.com>
> > 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 <tim.lewis@insyde.com>; Zeng, Star
> > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D
> > <michael.d.kinney@intel.com>
> > Cc: Gao, Liming <liming.gao@intel.com>
> > 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 <michael.d.kinney@intel.com>; Zeng, Star
> > > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > Cc: Gao, Liming <liming.gao@intel.com>
> > > 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 <tim.lewis@insyde.com>; Zeng, Star
> > > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D
> > > <michael.d.kinney@intel.com>
> > > Cc: Gao, Liming <liming.gao@intel.com>
> > > 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 <michael.d.kinney@intel.com>; Zeng, Star
> > > > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > > Cc: Gao, Liming <liming.gao@intel.com>
> > > > 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 <tim.lewis@insyde.com>; Zeng, Star
> > > > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D
> > > > <michael.d.kinney@intel.com>
> > > > Cc: Gao, Liming <liming.gao@intel.com>
> > > > 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 <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, Liming
> > > > > <liming.gao@intel.com>
> > > > > 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 <michael.d.kinney@intel.com>; Zeng, Star
> > > > > <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>
> > > > > 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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

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 <tim.lewis@insyde.com>; Zeng, Star <star.zeng@intel.com>; edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Gao, Liming <liming.gao@intel.com>
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 <michael.d.kinney@intel.com>; Zeng, Star 
> <star.zeng@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <tim.lewis@insyde.com>; Zeng, Star 
> <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
> <michael.d.kinney@intel.com>
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > Cc: Gao, Liming <liming.gao@intel.com>
> > 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 <tim.lewis@insyde.com>; Zeng, Star 
> > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
> > <michael.d.kinney@intel.com>
> > Cc: Gao, Liming <liming.gao@intel.com>
> > 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > Cc: Gao, Liming <liming.gao@intel.com>
> > > 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 <tim.lewis@insyde.com>; Zeng, Star 
> > > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
> > > <michael.d.kinney@intel.com>
> > > Cc: Gao, Liming <liming.gao@intel.com>
> > > 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > > > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > > Cc: Gao, Liming <liming.gao@intel.com>
> > > > 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 <tim.lewis@insyde.com>; Zeng, Star 
> > > > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael 
> > > > D <michael.d.kinney@intel.com>
> > > > Cc: Gao, Liming <liming.gao@intel.com>
> > > > 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 <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, 
> > > > > Liming <liming.gao@intel.com>
> > > > > 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > > > > <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>
> > > > > 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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Zeng, Star]

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 <michael.d.kinney@intel.com>; Zeng, Star <star.zeng@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>
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 <tim.lewis@insyde.com>; Zeng, Star <star.zeng@intel.com>; edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Gao, Liming <liming.gao@intel.com>
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 <michael.d.kinney@intel.com>; Zeng, Star 
> <star.zeng@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <tim.lewis@insyde.com>; Zeng, Star 
> <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
> <michael.d.kinney@intel.com>
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > Cc: Gao, Liming <liming.gao@intel.com>
> > 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 <tim.lewis@insyde.com>; Zeng, Star 
> > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
> > <michael.d.kinney@intel.com>
> > Cc: Gao, Liming <liming.gao@intel.com>
> > 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > Cc: Gao, Liming <liming.gao@intel.com>
> > > 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 <tim.lewis@insyde.com>; Zeng, Star 
> > > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
> > > <michael.d.kinney@intel.com>
> > > Cc: Gao, Liming <liming.gao@intel.com>
> > > 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > > > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > > Cc: Gao, Liming <liming.gao@intel.com>
> > > > 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 <tim.lewis@insyde.com>; Zeng, Star 
> > > > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael 
> > > > D <michael.d.kinney@intel.com>
> > > > Cc: Gao, Liming <liming.gao@intel.com>
> > > > 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 <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, 
> > > > > Liming <liming.gao@intel.com>
> > > > > 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > > > > <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>
> > > > > 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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

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 <tim.lewis@insyde.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>
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 <michael.d.kinney@intel.com>; Zeng, Star <star.zeng@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>
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 <tim.lewis@insyde.com>; Zeng, Star <star.zeng@intel.com>; edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Gao, Liming <liming.gao@intel.com>
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 <michael.d.kinney@intel.com>; Zeng, Star 
> <star.zeng@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <tim.lewis@insyde.com>; Zeng, Star 
> <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
> <michael.d.kinney@intel.com>
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > Cc: Gao, Liming <liming.gao@intel.com>
> > 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 <tim.lewis@insyde.com>; Zeng, Star 
> > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
> > <michael.d.kinney@intel.com>
> > Cc: Gao, Liming <liming.gao@intel.com>
> > 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > Cc: Gao, Liming <liming.gao@intel.com>
> > > 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 <tim.lewis@insyde.com>; Zeng, Star 
> > > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
> > > <michael.d.kinney@intel.com>
> > > Cc: Gao, Liming <liming.gao@intel.com>
> > > 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > > > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > > Cc: Gao, Liming <liming.gao@intel.com>
> > > > 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 <tim.lewis@insyde.com>; Zeng, Star 
> > > > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael 
> > > > D <michael.d.kinney@intel.com>
> > > > Cc: Gao, Liming <liming.gao@intel.com>
> > > > 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 <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, 
> > > > > Liming <liming.gao@intel.com>
> > > > > 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > > > > <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>
> > > > > 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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Zeng, Star]

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?


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 <star.zeng@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>
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 <tim.lewis@insyde.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>
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 <michael.d.kinney@intel.com>; Zeng, Star <star.zeng@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>
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 <tim.lewis@insyde.com>; Zeng, Star <star.zeng@intel.com>; edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Gao, Liming <liming.gao@intel.com>
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 <michael.d.kinney@intel.com>; Zeng, Star 
> <star.zeng@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <tim.lewis@insyde.com>; Zeng, Star 
> <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
> <michael.d.kinney@intel.com>
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > Cc: Gao, Liming <liming.gao@intel.com>
> > 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 <tim.lewis@insyde.com>; Zeng, Star 
> > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
> > <michael.d.kinney@intel.com>
> > Cc: Gao, Liming <liming.gao@intel.com>
> > 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > Cc: Gao, Liming <liming.gao@intel.com>
> > > 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 <tim.lewis@insyde.com>; Zeng, Star 
> > > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
> > > <michael.d.kinney@intel.com>
> > > Cc: Gao, Liming <liming.gao@intel.com>
> > > 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > > > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > > Cc: Gao, Liming <liming.gao@intel.com>
> > > > 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 <tim.lewis@insyde.com>; Zeng, Star 
> > > > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael 
> > > > D <michael.d.kinney@intel.com>
> > > > Cc: Gao, Liming <liming.gao@intel.com>
> > > > 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 <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, 
> > > > > Liming <liming.gao@intel.com>
> > > > > 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 <michael.d.kinney@intel.com>; Zeng, Star 
> > > > > <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>
> > > > > 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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Andrew Fish]

> On Apr 27, 2017, at 6:53 PM, Zeng, Star <star.zeng@intel.com> 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 <star.zeng@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <tim.lewis@insyde.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>
> 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 <michael.d.kinney@intel.com>; Zeng, Star <star.zeng@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <tim.lewis@insyde.com>; Zeng, Star <star.zeng@intel.com>; edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <michael.d.kinney@intel.com>; Zeng, Star 
>> <star.zeng@intel.com>; edk2-devel@lists.01.org
>> Cc: Gao, Liming <liming.gao@intel.com>
>> 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 <tim.lewis@insyde.com>; Zeng, Star 
>> <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
>> <michael.d.kinney@intel.com>
>> Cc: Gao, Liming <liming.gao@intel.com>
>> 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 <michael.d.kinney@intel.com>; Zeng, Star 
>>> <star.zeng@intel.com>; edk2-devel@lists.01.org
>>> Cc: Gao, Liming <liming.gao@intel.com>
>>> 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 <tim.lewis@insyde.com>; Zeng, Star 
>>> <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
>>> <michael.d.kinney@intel.com>
>>> Cc: Gao, Liming <liming.gao@intel.com>
>>> 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 <michael.d.kinney@intel.com>; Zeng, Star 
>>>> <star.zeng@intel.com>; edk2-devel@lists.01.org
>>>> Cc: Gao, Liming <liming.gao@intel.com>
>>>> 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 <tim.lewis@insyde.com>; Zeng, Star 
>>>> <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
>>>> <michael.d.kinney@intel.com>
>>>> Cc: Gao, Liming <liming.gao@intel.com>
>>>> 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 <michael.d.kinney@intel.com>; Zeng, Star 
>>>>> <star.zeng@intel.com>; edk2-devel@lists.01.org
>>>>> Cc: Gao, Liming <liming.gao@intel.com>
>>>>> 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 <tim.lewis@insyde.com>; Zeng, Star 
>>>>> <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael 
>>>>> D <michael.d.kinney@intel.com>
>>>>> Cc: Gao, Liming <liming.gao@intel.com>
>>>>> 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 <star.zeng@intel.com>; edk2-devel@lists.01.org
>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, 
>>>>>> Liming <liming.gao@intel.com>
>>>>>> 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 <michael.d.kinney@intel.com>; Zeng, Star 
>>>>>> <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>
>>>>>> 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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

Start,



The RFC adds a new mechanism for expressing a relationship between SKUs. The [SkuIds] section is not tied to PCDs.



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 other places where such information can be used. Therefore, publishing this information so that it can be used by other runtime agents besides the. PCD 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<mailto:star.zeng@intel.com>
Sent: Thursday, April 27, 2017 6:53 PM
To: Tim Lewis<mailto:tim.lewis@insyde.com>; Kinney, Michael D<mailto:michael.d.kinney@intel.com>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming<mailto:liming.gao@intel.com>; Zeng, Star<mailto:star.zeng@intel.com>
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 *simplify 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 <star.zeng@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>
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 <tim.lewis@insyde.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>
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 <michael.d.kinney@intel.com>; Zeng, Star <star.zeng@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>
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 <tim.lewis@insyde.com>; Zeng, Star <star.zeng@intel.com>; edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Gao, Liming <liming.gao@intel.com>
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 <michael.d.kinney@intel.com>; Zeng, Star
> <star.zeng@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <tim.lewis@insyde.com>; Zeng, Star
> <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D
> <michael.d.kinney@intel.com>
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <michael.d.kinney@intel.com>; Zeng, Star
> > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > Cc: Gao, Liming <liming.gao@intel.com>
> > 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 <tim.lewis@insyde.com>; Zeng, Star
> > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D
> > <michael.d.kinney@intel.com>
> > Cc: Gao, Liming <liming.gao@intel.com>
> > 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 <michael.d.kinney@intel.com>; Zeng, Star
> > > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > Cc: Gao, Liming <liming.gao@intel.com>
> > > 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 <tim.lewis@insyde.com>; Zeng, Star
> > > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D
> > > <michael.d.kinney@intel.com>
> > > Cc: Gao, Liming <liming.gao@intel.com>
> > > 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 <michael.d.kinney@intel.com>; Zeng, Star
> > > > <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > > Cc: Gao, Liming <liming.gao@intel.com>
> > > > 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 <tim.lewis@insyde.com>; Zeng, Star
> > > > <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael
> > > > D <michael.d.kinney@intel.com>
> > > > Cc: Gao, Liming <liming.gao@intel.com>
> > > > 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 <star.zeng@intel.com>; edk2-devel@lists.01.org
> > > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao,
> > > > > Liming <liming.gao@intel.com>
> > > > > 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 <michael.d.kinney@intel.com>; Zeng, Star
> > > > > <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>
> > > > > 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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Zeng, Star]

Andrew,

It is definitely supported with or without this RFC. No impact to this by this RFC.

The code path could use GetSku() to be different after an early platform PEIM called SetSku().

Thanks,
Star
-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Andrew Fish
Sent: Friday, April 28, 2017 10:03 AM
To: Zeng, Star <star.zeng@intel.com>
Cc: Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org; Tim Lewis <tim.lewis@insyde.com>; Gao, Liming <liming.gao@intel.com>
Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance


> On Apr 27, 2017, at 6:53 PM, Zeng, Star <star.zeng@intel.com> 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 <star.zeng@intel.com>; Kinney, Michael D 
> <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <tim.lewis@insyde.com>; Kinney, Michael D 
> <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star 
> <star.zeng@intel.com>
> 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 <michael.d.kinney@intel.com>; Zeng, Star 
> <star.zeng@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <tim.lewis@insyde.com>; Zeng, Star 
> <star.zeng@intel.com>; edk2-devel@lists.01.org; Kinney, Michael D 
> <michael.d.kinney@intel.com>
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 <michael.d.kinney@intel.com>; Zeng, Star 
>> <star.zeng@intel.com>; edk2-devel@lists.01.org
>> Cc: Gao, Liming <liming.gao@intel.com>
>> 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 <tim.lewis@insyde.com>; Zeng, Star 
>> <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
>> <michael.d.kinney@intel.com>
>> Cc: Gao, Liming <liming.gao@intel.com>
>> 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 <michael.d.kinney@intel.com>; Zeng, Star 
>>> <star.zeng@intel.com>; edk2-devel@lists.01.org
>>> Cc: Gao, Liming <liming.gao@intel.com>
>>> 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 <tim.lewis@insyde.com>; Zeng, Star 
>>> <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
>>> <michael.d.kinney@intel.com>
>>> Cc: Gao, Liming <liming.gao@intel.com>
>>> 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 <michael.d.kinney@intel.com>; Zeng, Star 
>>>> <star.zeng@intel.com>; edk2-devel@lists.01.org
>>>> Cc: Gao, Liming <liming.gao@intel.com>
>>>> 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 <tim.lewis@insyde.com>; Zeng, Star 
>>>> <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael D 
>>>> <michael.d.kinney@intel.com>
>>>> Cc: Gao, Liming <liming.gao@intel.com>
>>>> 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 <michael.d.kinney@intel.com>; Zeng, Star 
>>>>> <star.zeng@intel.com>; edk2-devel@lists.01.org
>>>>> Cc: Gao, Liming <liming.gao@intel.com>
>>>>> 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 <tim.lewis@insyde.com>; Zeng, Star 
>>>>> <star.zeng@intel.com>; edk2- devel@lists.01.org; Kinney, Michael 
>>>>> D <michael.d.kinney@intel.com>
>>>>> Cc: Gao, Liming <liming.gao@intel.com>
>>>>> 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 <star.zeng@intel.com>; edk2-devel@lists.01.org
>>>>>> Cc: Kinney, Michael D <michael.d.kinney@intel.com>; Gao, 
>>>>>> Liming <liming.gao@intel.com>
>>>>>> 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 <michael.d.kinney@intel.com>; Zeng, Star 
>>>>>> <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>
>>>>>> 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

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Kinney, Michael D]

Hi Star,

The 2nd RFC for SKUs add some autogen to support setting the SKU from a platform PEIM.

We should consider additional autogen that allows a module to determine the relationships between SKUs.  This additional autogen is not required for the 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 <star.zeng@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance


Start,



The RFC adds a new mechanism for expressing a relationship between SKUs. The [SkuIds] section is not tied to PCDs.



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 other places where such information can be used. Therefore, publishing this information so that it can be used by other runtime agents besides the. PCD 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<mailto:star.zeng@intel.com>
Sent: Thursday, April 27, 2017 6:53 PM
To: Tim Lewis<mailto:tim.lewis@insyde.com>; Kinney, Michael D<mailto:michael.d.kinney@intel.com>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming<mailto:liming.gao@intel.com>; Zeng, Star<mailto:star.zeng@intel.com>
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 *simplify 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
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 <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
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 <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star
> <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star
> <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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 <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star
> > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star
> > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D
> > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > 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 <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star
> > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star
> > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D
> > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > 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 <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star
> > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star
> > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael
> > > > D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Gao,
> > > > > Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > 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<mailto:edk2-devel@lists.01.org>
> > > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star
> > > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > 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<mailto:edk2-devel@lists.01.org>
> > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > > _______________________________________________
> > > > > edk2-devel mailing list
> > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > _______________________________________________
> > > > edk2-devel mailing list
> > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > _______________________________________________
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > https://lists.01.org/mailman/listinfo/edk2-devel
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Zeng, Star]

Tim,

Could you help share and explain the use cases in your code base that is using [SkuIds] section and SKUID_IDENTIFIER for others beyond PCD?
Then we can consider more in [RFC] PCD: Extended SKU support. Or do you have 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 <tim.lewis@insyde.com>; Zeng, Star <star.zeng@intel.com>; edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>
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 platform PEIM.

We should consider additional autogen that allows a module to determine the relationships between SKUs.  This additional autogen is not required for the 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance


Start,



The RFC adds a new mechanism for expressing a relationship between SKUs. The [SkuIds] section is not tied to PCDs.



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 other places where such information can be used. Therefore, publishing this information so that it can be used by other runtime agents besides the. PCD 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<mailto:star.zeng@intel.com>
Sent: Thursday, April 27, 2017 6:53 PM
To: Tim Lewis<mailto:tim.lewis@insyde.com>; Kinney, Michael D<mailto:michael.d.kinney@intel.com>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming<mailto:liming.gao@intel.com>; Zeng, Star<mailto:star.zeng@intel.com>
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 *simplify 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
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 <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
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 <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star
> <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star
> <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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 <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star
> > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star
> > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D
> > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > 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 <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star
> > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star
> > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D
> > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > 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 <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star
> > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star
> > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael
> > > > D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Gao,
> > > > > Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > 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<mailto:edk2-devel@lists.01.org>
> > > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star
> > > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > 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<mailto:edk2-devel@lists.01.org>
> > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > > _______________________________________________
> > > > > edk2-devel mailing list
> > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > _______________________________________________
> > > > edk2-devel mailing list
> > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > _______________________________________________
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > https://lists.01.org/mailman/listinfo/edk2-devel
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

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 resources. 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. We 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 yours exactly)

// Select which SKUs
SKUID_IDENTIFIER = 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 other 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[] = {SKUID_IDENTIFIER_DEFAULT};
UINT32 *SkuId;
UINT32 CurrentSkuId;
BOOLEAN Found;
VOID *Resource;

CurrentSkuId = PcdGetSkuId();

SkuId = SkuIdDefaults;
Found = (CurrentSkuId == 0); // so that DEFAULT will also return TRUE;
while (*SkuId != 0) {
  if (*SkuId == CurrentSkuId) {
    Found = TRUE;
    Break;
  }
  while (*SkuId != 0) {
     SkuId++;
  }
  SkuId++;
}
if (!Found) {
  //error, because SKU ID was not found in array
}

Resource = NULL;
while (!GetResourceForSkuId(*SkuId, &Resource) && *SkuId == 0) {
  *SkuId++;
}
If (Resource == 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 <tim.lewis@insyde.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>
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 using [SkuIds] section and SKUID_IDENTIFIER for others beyond PCD?
Then we can consider more in [RFC] PCD: Extended SKU support. Or do you have 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
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 platform PEIM.

We should consider additional autogen that allows a module to determine the relationships between SKUs.  This additional autogen is not required for the 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance


Start,



The RFC adds a new mechanism for expressing a relationship between SKUs. The [SkuIds] section is not tied to PCDs.



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 other places where such information can be used. Therefore, publishing this information so that it can be used by other runtime agents besides the. PCD 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<mailto:star.zeng@intel.com>
Sent: Thursday, April 27, 2017 6:53 PM
To: Tim Lewis<mailto:tim.lewis@insyde.com>; Kinney, Michael D<mailto:michael.d.kinney@intel.com>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming<mailto:liming.gao@intel.com>; Zeng, Star<mailto:star.zeng@intel.com>
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 *simplify 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
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 <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
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 <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star
> <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star
> <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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 <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star
> > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star
> > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D
> > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > 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 <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star
> > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star
> > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D
> > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > 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 <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star
> > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star
> > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael
> > > > D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Gao,
> > > > > Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > 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<mailto:edk2-devel@lists.01.org>
> > > > > Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star
> > > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > 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<mailto:edk2-devel@lists.01.org>
> > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > > _______________________________________________
> > > > > edk2-devel mailing list
> > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > _______________________________________________
> > > > edk2-devel mailing list
> > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > _______________________________________________
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > https://lists.01.org/mailman/listinfo/edk2-devel
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Zeng, Star]

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) between 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 configuring for multiple SKUs in DSC, I want to emphasize it is in DSC, it is to cover the case that some non-DEFAULT SKU has much PCD 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 the rule that DEFAULT SKU PCD value will be returned if the specified SKU PCD value 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 = FALSE;
  for (Index = 0; Index < SkuIdTable[0]; Index++) {
    if (PeiPcdDb->SystemSkuId == SkuIdTable[Index + 1]) {
      FoundSku = TRUE;
      break;
    }
  }

  //
  // Find the default SKU ID entry in SKU ID table.
  //
  if(!FoundSku) {
    for (Index = 0; Index < SkuIdTable[0]; Index++) {
      if (0 == SkuIdTable[Index + 1]) {
        break;
      }
    }
  }


The usage case you provided for other resources beyond PCD could be like below?

CurrentSkuId = PcdGetSkuId();

Resource = NULL;
if (!GetResourceForSkuId(CurrentSkuId, &Resource) {
  // try DEFAULT SKU
  GetResourceForSkuId(0, &Resource);
}
If (Resource == 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 <star.zeng@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>
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 resources. 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. We 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 yours exactly)

// Select which SKUs
SKUID_IDENTIFIER = 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 other 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[] = {SKUID_IDENTIFIER_DEFAULT};
UINT32 *SkuId;
UINT32 CurrentSkuId;
BOOLEAN Found;
VOID *Resource;

CurrentSkuId = PcdGetSkuId();

SkuId = SkuIdDefaults;
Found = (CurrentSkuId == 0); // so that DEFAULT will also return TRUE; while (*SkuId != 0) {
  if (*SkuId == CurrentSkuId) {
    Found = TRUE;
    Break;
  }
  while (*SkuId != 0) {
     SkuId++;
  }
  SkuId++;
}
if (!Found) {
  //error, because SKU ID was not found in array }

Resource = NULL;
while (!GetResourceForSkuId(*SkuId, &Resource) && *SkuId == 0) {
  *SkuId++;
}
If (Resource == 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 <tim.lewis@insyde.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>
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 using [SkuIds] section and SKUID_IDENTIFIER for others beyond PCD?
Then we can consider more in [RFC] PCD: Extended SKU support. Or do you have 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
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 platform PEIM.

We should consider additional autogen that allows a module to determine the relationships between SKUs.  This additional autogen is not required for the 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance


Start,



The RFC adds a new mechanism for expressing a relationship between SKUs. The [SkuIds] section is not tied to PCDs.



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 other places where such information can be used. Therefore, publishing this information so that it can be used by other runtime agents besides the. PCD 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<mailto:star.zeng@intel.com>
Sent: Thursday, April 27, 2017 6:53 PM
To: Tim Lewis<mailto:tim.lewis@insyde.com>; Kinney, Michael D<mailto:michael.d.kinney@intel.com>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming<mailto:liming.gao@intel.com>; Zeng, Star<mailto:star.zeng@intel.com>
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 *simplify 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
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 <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
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 
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, 
> Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; 
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; 
> Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D 
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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 
> > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; 
> > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; 
> > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; 
> > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> > devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D 
> > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > 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 
> > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; 
> > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; 
> > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > Cc: Gao, Liming 
> > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; 
> > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; 
> > > edk2- devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, 
> > > Michael D 
> > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > Cc: Gao, Liming 
> > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > 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 
> > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; 
> > > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; 
> > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > Cc: Gao, Liming 
> > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > 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 
> > > > <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star 
> > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> > > > devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D 
> > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > Cc: Gao, Liming 
> > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > 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 
> > > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; 
> > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > Cc: Kinney, Michael D 
> > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>
> > > > > >; Gao, Liming 
> > > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > 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<mailto:edk2-devel@lists.01.org>
> > > > > Cc: Kinney, Michael D 
> > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>
> > > > > >; Zeng, Star 
> > > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Gao, Liming 
> > > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > 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<mailto:edk2-devel@lists.01.org>
> > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > > _______________________________________________
> > > > > edk2-devel mailing list
> > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > _______________________________________________
> > > > edk2-devel mailing list
> > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > _______________________________________________
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > https://lists.01.org/mailman/listinfo/edk2-devel
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto: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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

Star --

I understand your use case. We use the same behavior for other resources besides PCD. 

All we are asking is that this data that is used by the build tools is also available in some form at runtime. 

Thanks,

Tim
 


-----Original Message-----
From: Zeng, Star [mailto:star.zeng@intel.com] 
Sent: Thursday, May 04, 2017 6:42 AM
To: Tim Lewis <tim.lewis@insyde.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>
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) between 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 configuring for multiple SKUs in DSC, I want to emphasize it is in DSC, it is to cover the case that some non-DEFAULT SKU has much PCD 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 the rule that DEFAULT SKU PCD value will be returned if the specified SKU PCD value 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 = FALSE;
  for (Index = 0; Index < SkuIdTable[0]; Index++) {
    if (PeiPcdDb->SystemSkuId == SkuIdTable[Index + 1]) {
      FoundSku = TRUE;
      break;
    }
  }

  //
  // Find the default SKU ID entry in SKU ID table.
  //
  if(!FoundSku) {
    for (Index = 0; Index < SkuIdTable[0]; Index++) {
      if (0 == SkuIdTable[Index + 1]) {
        break;
      }
    }
  }


The usage case you provided for other resources beyond PCD could be like below?

CurrentSkuId = PcdGetSkuId();

Resource = NULL;
if (!GetResourceForSkuId(CurrentSkuId, &Resource) {
  // try DEFAULT SKU
  GetResourceForSkuId(0, &Resource);
}
If (Resource == 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 <star.zeng@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>
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 resources. 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. We 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 yours exactly)

// Select which SKUs
SKUID_IDENTIFIER = 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 other 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[] = {SKUID_IDENTIFIER_DEFAULT};
UINT32 *SkuId;
UINT32 CurrentSkuId;
BOOLEAN Found;
VOID *Resource;

CurrentSkuId = PcdGetSkuId();

SkuId = SkuIdDefaults;
Found = (CurrentSkuId == 0); // so that DEFAULT will also return TRUE; while (*SkuId != 0) {
  if (*SkuId == CurrentSkuId) {
    Found = TRUE;
    Break;
  }
  while (*SkuId != 0) {
     SkuId++;
  }
  SkuId++;
}
if (!Found) {
  //error, because SKU ID was not found in array }

Resource = NULL;
while (!GetResourceForSkuId(*SkuId, &Resource) && *SkuId == 0) {
  *SkuId++;
}
If (Resource == 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 <tim.lewis@insyde.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>
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 using [SkuIds] section and SKUID_IDENTIFIER for others beyond PCD?
Then we can consider more in [RFC] PCD: Extended SKU support. Or do you have 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
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 platform PEIM.

We should consider additional autogen that allows a module to determine the relationships between SKUs.  This additional autogen is not required for the 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance


Start,



The RFC adds a new mechanism for expressing a relationship between SKUs. The [SkuIds] section is not tied to PCDs.



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 other places where such information can be used. Therefore, publishing this information so that it can be used by other runtime agents besides the. PCD 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<mailto:star.zeng@intel.com>
Sent: Thursday, April 27, 2017 6:53 PM
To: Tim Lewis<mailto:tim.lewis@insyde.com>; Kinney, Michael D<mailto:michael.d.kinney@intel.com>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming<mailto:liming.gao@intel.com>; Zeng, Star<mailto:star.zeng@intel.com>
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 *simplify 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
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 <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
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
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, 
> Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>;
> Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D 
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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
> > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>;
> > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> > devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D 
> > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > 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
> > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > Cc: Gao, Liming
> > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>;
> > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > edk2- devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, 
> > > Michael D 
> > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > Cc: Gao, Liming
> > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > 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
> > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > Cc: Gao, Liming
> > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > 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
> > > > <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star 
> > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> > > > devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D 
> > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > Cc: Gao, Liming
> > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > 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
> > > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > Cc: Kinney, Michael D
> > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>
> > > > > >; Gao, Liming
> > > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > 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<mailto:edk2-devel@lists.01.org>
> > > > > Cc: Kinney, Michael D
> > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>
> > > > > >; Zeng, Star
> > > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Gao, Liming 
> > > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > 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<mailto:edk2-devel@lists.01.org>
> > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > > _______________________________________________
> > > > > edk2-devel mailing list
> > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > _______________________________________________
> > > > edk2-devel mailing list
> > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > _______________________________________________
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > https://lists.01.org/mailman/listinfo/edk2-devel
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto: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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Zeng, Star]

Tim,

In your code base, there are other tools beyond BaseTools to parse the [SkuIds] section and SKUID_IDENTIFIER in DSC, right?

The boot time usage (use the value in DEFAULT SKU instead if the value 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 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 SKUID_IDENTIFIER_DEFAULT 2,1,0,1,0,0.


The DSC syntax extension in this RFC is OPTIONAL, the backward 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 of PCD related RFCs (include Structure PCD, etc). Mike and Liming can help confirm 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 <star.zeng@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>
Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

Star --

I understand your use case. We use the same behavior for other resources besides PCD. 

All we are asking is that this data that is used by the build tools is also available in some form at runtime. 

Thanks,

Tim
 


-----Original Message-----
From: Zeng, Star [mailto:star.zeng@intel.com]
Sent: Thursday, May 04, 2017 6:42 AM
To: Tim Lewis <tim.lewis@insyde.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>
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) between 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 configuring for multiple SKUs in DSC, I want to emphasize it is in DSC, it is to cover the case that some non-DEFAULT SKU has much PCD 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 the rule that DEFAULT SKU PCD value will be returned if the specified SKU PCD value 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 = FALSE;
  for (Index = 0; Index < SkuIdTable[0]; Index++) {
    if (PeiPcdDb->SystemSkuId == SkuIdTable[Index + 1]) {
      FoundSku = TRUE;
      break;
    }
  }

  //
  // Find the default SKU ID entry in SKU ID table.
  //
  if(!FoundSku) {
    for (Index = 0; Index < SkuIdTable[0]; Index++) {
      if (0 == SkuIdTable[Index + 1]) {
        break;
      }
    }
  }


The usage case you provided for other resources beyond PCD could be like below?

CurrentSkuId = PcdGetSkuId();

Resource = NULL;
if (!GetResourceForSkuId(CurrentSkuId, &Resource) {
  // try DEFAULT SKU
  GetResourceForSkuId(0, &Resource);
}
If (Resource == 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 <star.zeng@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>
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 resources. 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. We 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 yours exactly)

// Select which SKUs
SKUID_IDENTIFIER = 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 other 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[] = {SKUID_IDENTIFIER_DEFAULT};
UINT32 *SkuId;
UINT32 CurrentSkuId;
BOOLEAN Found;
VOID *Resource;

CurrentSkuId = PcdGetSkuId();

SkuId = SkuIdDefaults;
Found = (CurrentSkuId == 0); // so that DEFAULT will also return TRUE; while (*SkuId != 0) {
  if (*SkuId == CurrentSkuId) {
    Found = TRUE;
    Break;
  }
  while (*SkuId != 0) {
     SkuId++;
  }
  SkuId++;
}
if (!Found) {
  //error, because SKU ID was not found in array }

Resource = NULL;
while (!GetResourceForSkuId(*SkuId, &Resource) && *SkuId == 0) {
  *SkuId++;
}
If (Resource == 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 <tim.lewis@insyde.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>
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 using [SkuIds] section and SKUID_IDENTIFIER for others beyond PCD?
Then we can consider more in [RFC] PCD: Extended SKU support. Or do you have 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
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 platform PEIM.

We should consider additional autogen that allows a module to determine the relationships between SKUs.  This additional autogen is not required for the 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance


Start,



The RFC adds a new mechanism for expressing a relationship between SKUs. The [SkuIds] section is not tied to PCDs.



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 other places where such information can be used. Therefore, publishing this information so that it can be used by other runtime agents besides the. PCD 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<mailto:star.zeng@intel.com>
Sent: Thursday, April 27, 2017 6:53 PM
To: Tim Lewis<mailto:tim.lewis@insyde.com>; Kinney, Michael D<mailto:michael.d.kinney@intel.com>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming<mailto:liming.gao@intel.com>; Zeng, Star<mailto:star.zeng@intel.com>
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 *simplify 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
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 <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
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
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, 
> Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>;
> Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D 
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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
> > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>;
> > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> > devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D 
> > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > 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
> > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > Cc: Gao, Liming
> > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>;
> > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > edk2- devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, 
> > > Michael D 
> > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > Cc: Gao, Liming
> > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > 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
> > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > Cc: Gao, Liming
> > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > 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
> > > > <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star 
> > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> > > > devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D 
> > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > Cc: Gao, Liming
> > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > 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
> > > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > Cc: Kinney, Michael D
> > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>
> > > > > >; Gao, Liming
> > > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > 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<mailto:edk2-devel@lists.01.org>
> > > > > Cc: Kinney, Michael D
> > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>
> > > > > >; Zeng, Star
> > > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Gao, Liming 
> > > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > 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<mailto:edk2-devel@lists.01.org>
> > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > > _______________________________________________
> > > > > edk2-devel mailing list
> > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > _______________________________________________
> > > > edk2-devel mailing list
> > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > _______________________________________________
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > https://lists.01.org/mailman/listinfo/edk2-devel
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto: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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

Star,

We would like to track the exact same defaulting as is used by PCDs. Otherwise it is confusing to users. If we were to say, "Use the this defaulting scheme for PCDs, but ignore it for all of the other runtime resource selection." 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 <tim.lewis@insyde.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Zeng, Star <star.zeng@intel.com>; Gao, Liming <liming.gao@intel.com>
Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

Tim,

In your code base, there are other tools beyond BaseTools to parse the [SkuIds] section and SKUID_IDENTIFIER in DSC, right?

The boot time usage (use the value in DEFAULT SKU instead if the value 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 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 SKUID_IDENTIFIER_DEFAULT 2,1,0,1,0,0.


The DSC syntax extension in this RFC is OPTIONAL, the backward 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 of PCD related RFCs (include Structure PCD, etc). Mike and Liming can help confirm 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 <star.zeng@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>
Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance

Star --

I understand your use case. We use the same behavior for other resources besides PCD. 

All we are asking is that this data that is used by the build tools is also available in some form at runtime. 

Thanks,

Tim
 


-----Original Message-----
From: Zeng, Star [mailto:star.zeng@intel.com]
Sent: Thursday, May 04, 2017 6:42 AM
To: Tim Lewis <tim.lewis@insyde.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>
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) between 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 configuring for multiple SKUs in DSC, I want to emphasize it is in DSC, it is to cover the case that some non-DEFAULT SKU has much PCD 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 the rule that DEFAULT SKU PCD value will be returned if the specified SKU PCD value 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 = FALSE;
  for (Index = 0; Index < SkuIdTable[0]; Index++) {
    if (PeiPcdDb->SystemSkuId == SkuIdTable[Index + 1]) {
      FoundSku = TRUE;
      break;
    }
  }

  //
  // Find the default SKU ID entry in SKU ID table.
  //
  if(!FoundSku) {
    for (Index = 0; Index < SkuIdTable[0]; Index++) {
      if (0 == SkuIdTable[Index + 1]) {
        break;
      }
    }
  }


The usage case you provided for other resources beyond PCD could be like below?

CurrentSkuId = PcdGetSkuId();

Resource = NULL;
if (!GetResourceForSkuId(CurrentSkuId, &Resource) {
  // try DEFAULT SKU
  GetResourceForSkuId(0, &Resource);
}
If (Resource == 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 <star.zeng@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>
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 resources. 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. We 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 yours exactly)

// Select which SKUs
SKUID_IDENTIFIER = 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 other 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[] = {SKUID_IDENTIFIER_DEFAULT};
UINT32 *SkuId;
UINT32 CurrentSkuId;
BOOLEAN Found;
VOID *Resource;

CurrentSkuId = PcdGetSkuId();

SkuId = SkuIdDefaults;
Found = (CurrentSkuId == 0); // so that DEFAULT will also return TRUE; while (*SkuId != 0) {
  if (*SkuId == CurrentSkuId) {
    Found = TRUE;
    Break;
  }
  while (*SkuId != 0) {
     SkuId++;
  }
  SkuId++;
}
if (!Found) {
  //error, because SKU ID was not found in array }

Resource = NULL;
while (!GetResourceForSkuId(*SkuId, &Resource) && *SkuId == 0) {
  *SkuId++;
}
If (Resource == 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 <tim.lewis@insyde.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>
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 using [SkuIds] section and SKUID_IDENTIFIER for others beyond PCD?
Then we can consider more in [RFC] PCD: Extended SKU support. Or do you have 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
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 platform PEIM.

We should consider additional autogen that allows a module to determine the relationships between SKUs.  This additional autogen is not required for the 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance


Start,



The RFC adds a new mechanism for expressing a relationship between SKUs. The [SkuIds] section is not tied to PCDs.



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 other places where such information can be used. Therefore, publishing this information so that it can be used by other runtime agents besides the. PCD 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<mailto:star.zeng@intel.com>
Sent: Thursday, April 27, 2017 6:53 PM
To: Tim Lewis<mailto:tim.lewis@insyde.com>; Kinney, Michael D<mailto:michael.d.kinney@intel.com>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming<mailto:liming.gao@intel.com>; Zeng, Star<mailto:star.zeng@intel.com>
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 *simplify 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
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 <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
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
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng, 
> Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>;
> Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D 
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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
> > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>;
> > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> > devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D 
> > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > 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
> > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > Cc: Gao, Liming
> > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>;
> > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > edk2- devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, 
> > > Michael D 
> > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > Cc: Gao, Liming
> > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > 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
> > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > Cc: Gao, Liming
> > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > 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
> > > > <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star 
> > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> > > > devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D 
> > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > Cc: Gao, Liming
> > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > 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
> > > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > Cc: Kinney, Michael D
> > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>
> > > > > >; Gao, Liming
> > > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > 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<mailto:edk2-devel@lists.01.org>
> > > > > Cc: Kinney, Michael D
> > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>
> > > > > >; Zeng, Star
> > > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Gao, Liming 
> > > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > 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<mailto:edk2-devel@lists.01.org>
> > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > > _______________________________________________
> > > > > edk2-devel mailing list
> > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > _______________________________________________
> > > > edk2-devel mailing list
> > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > _______________________________________________
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > https://lists.01.org/mailman/listinfo/edk2-devel
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto: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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Kinney, Michael D]

Star,

I think Tim's feedback is a request for an additional feature 
on top of this RFC.  I do not see any requests for changes to
the proposed syntax extensions.  I agree that implementing these
new feature in an edk2-staging branch makes a lot of sense.
 
Since Tim's request is about access to the SKU relationships from
FW modules when the FW module executes, let's discuss this from
an API perspective instead 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 SKU is related to other SKUs.  Those other modules can
start with LibPcdGetSku() 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 file.  This derivative concept can be thought
of as parent to child link between the 2 SKUs.  We can draw this 
visually as a tree with parent child relationships between all the
SKUs.

Now from a module that calls LibPcdGetSku(), the module may want
to know who the parent SKU is.  The information we have about the
parent SKU is the SKU 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 the parent SKU.

So the request here is to extend the autogen to support a lookup
of the parent SKU given any valid SKU ID value.

Thanks,

Mike
 
> -----Original Message-----
> From: Zeng, Star
> Sent: Friday, May 5, 2017 3:08 AM
> To: Tim Lewis <tim.lewis@insyde.com>; Kinney, Michael D <michael.d.kinney@intel.com>;
> edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>
> Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance
> 
> Tim,
> 
> In your code base, there are other tools beyond BaseTools to parse the [SkuIds]
> section and SKUID_IDENTIFIER in DSC, right?
> 
> The boot time usage (use the value in DEFAULT SKU instead if the value 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 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
> SKUID_IDENTIFIER_DEFAULT 2,1,0,1,0,0.
> 
> 
> The DSC syntax extension in this RFC is OPTIONAL, the backward 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 of PCD related
> RFCs (include Structure PCD, etc). Mike and Liming can help confirm 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 <star.zeng@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>;
> edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance
> 
> Star --
> 
> I understand your use case. We use the same behavior for other resources besides PCD.
> 
> All we are asking is that this data that is used by the build tools is also available
> in some form at runtime.
> 
> Thanks,
> 
> Tim
> 
> 
> 
> -----Original Message-----
> From: Zeng, Star [mailto:star.zeng@intel.com]
> Sent: Thursday, May 04, 2017 6:42 AM
> To: Tim Lewis <tim.lewis@insyde.com>; Kinney, Michael D <michael.d.kinney@intel.com>;
> edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>
> 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) between 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 configuring for
> multiple SKUs in DSC, I want to emphasize it is in DSC, it is to cover the case that
> some non-DEFAULT SKU has much PCD 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 the rule that
> DEFAULT SKU PCD value will be returned if the specified SKU PCD value 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 = FALSE;
>   for (Index = 0; Index < SkuIdTable[0]; Index++) {
>     if (PeiPcdDb->SystemSkuId == SkuIdTable[Index + 1]) {
>       FoundSku = TRUE;
>       break;
>     }
>   }
> 
>   //
>   // Find the default SKU ID entry in SKU ID table.
>   //
>   if(!FoundSku) {
>     for (Index = 0; Index < SkuIdTable[0]; Index++) {
>       if (0 == SkuIdTable[Index + 1]) {
>         break;
>       }
>     }
>   }
> 
> 
> The usage case you provided for other resources beyond PCD could be like below?
> 
> CurrentSkuId = PcdGetSkuId();
> 
> Resource = NULL;
> if (!GetResourceForSkuId(CurrentSkuId, &Resource) {
>   // try DEFAULT SKU
>   GetResourceForSkuId(0, &Resource);
> }
> If (Resource == 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 <star.zeng@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>;
> edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 resources. 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. We 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 yours exactly)
> 
> // Select which SKUs
> SKUID_IDENTIFIER = 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 other 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[] = {SKUID_IDENTIFIER_DEFAULT};
> UINT32 *SkuId;
> UINT32 CurrentSkuId;
> BOOLEAN Found;
> VOID *Resource;
> 
> CurrentSkuId = PcdGetSkuId();
> 
> SkuId = SkuIdDefaults;
> Found = (CurrentSkuId == 0); // so that DEFAULT will also return TRUE; while (*SkuId
> != 0) {
>   if (*SkuId == CurrentSkuId) {
>     Found = TRUE;
>     Break;
>   }
>   while (*SkuId != 0) {
>      SkuId++;
>   }
>   SkuId++;
> }
> if (!Found) {
>   //error, because SKU ID was not found in array }
> 
> Resource = NULL;
> while (!GetResourceForSkuId(*SkuId, &Resource) && *SkuId == 0) {
>   *SkuId++;
> }
> If (Resource == 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 <tim.lewis@insyde.com>; Kinney, Michael D <michael.d.kinney@intel.com>;
> edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>
> 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 using
> [SkuIds] section and SKUID_IDENTIFIER for others beyond PCD?
> Then we can consider more in [RFC] PCD: Extended SKU support. Or do you have 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star
> <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-
> devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Kinney, Michael D
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Zeng, Star
> <star.zeng@intel.com<mailto:star.zeng@intel.com>>
> 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 platform PEIM.
> 
> We should consider additional autogen that allows a module to determine the
> relationships between SKUs.  This additional autogen is not required for the 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Kinney, Michael D
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-
> devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Zeng, Star
> <star.zeng@intel.com<mailto:star.zeng@intel.com>>
> Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance
> 
> 
> Start,
> 
> 
> 
> The RFC adds a new mechanism for expressing a relationship between SKUs. The [SkuIds]
> section is not tied to PCDs.
> 
> 
> 
> 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 other places where
> such information can be used. Therefore, publishing this information so that it can be
> used by other runtime agents besides the. PCD 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<mailto:star.zeng@intel.com>
> Sent: Thursday, April 27, 2017 6:53 PM
> To: Tim Lewis<mailto:tim.lewis@insyde.com>; Kinney, Michael
> D<mailto:michael.d.kinney@intel.com>; edk2-devel@lists.01.org<mailto:edk2-
> devel@lists.01.org>
> Cc: Gao, Liming<mailto:liming.gao@intel.com>; Zeng, Star<mailto:star.zeng@intel.com>
> 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 *simplify 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Kinney, Michael D
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-
> devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Kinney, Michael D
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2-
> devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; Zeng, Star
> <star.zeng@intel.com<mailto:star.zeng@intel.com>>
> 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 <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-
> devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star
> <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-
> devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Kinney, Michael D
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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
> > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Zeng,
> > Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>;
> > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-
> > devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D
> > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > 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
> > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>;
> > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-
> > > devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D
> > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > 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
> > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > Cc: Gao, Liming
> > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>;
> > > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > > edk2- devel@lists.01.org<mailto:devel@lists.01.org>; Kinney,
> > > > Michael D
> > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > Cc: Gao, Liming
> > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > 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
> > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > Cc: Gao, Liming
> > > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > 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
> > > > > <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, Star
> > > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2-
> > > > > devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D
> > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > > Cc: Gao, Liming
> > > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > 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
> > > > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > > Cc: Kinney, Michael D
> > > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>
> > > > > > >; Gao, Liming
> > > > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > > 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<mailto:edk2-devel@lists.01.org>
> > > > > > Cc: Kinney, Michael D
> > > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>
> > > > > > >; Zeng, Star
> > > > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Gao, Liming
> > > > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > > 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<mailto:edk2-devel@lists.01.org>
> > > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > > > _______________________________________________
> > > > > > edk2-devel mailing list
> > > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > > _______________________________________________
> > > > > edk2-devel mailing list
> > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > _______________________________________________
> > > > edk2-devel mailing list
> > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > _______________________________________________
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > https://lists.01.org/mailman/listinfo/edk2-devel
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto: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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Zeng, Star]

Thanks all for the comments to this RFC.

I have sent out the V2 of this RFC at https://www.mail-archive.com/edk2-devel@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 = LibPcdGetSku ();

Resource = NULL;
while (!GetResourceForSkuId (SkuId, &Resource) && SkuId != 0) {
  SkuId = PcdGetParentSkuId (SkuId);
}
If (Resource == NULL) {
  // error, no resource found.
}


Thanks,
Star
-----Original Message-----
From: Kinney, Michael D 
Sent: Saturday, May 6, 2017 12:07 AM
To: Zeng, Star <star.zeng@intel.com>; Tim Lewis <tim.lewis@insyde.com>; edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Gao, Liming <liming.gao@intel.com>
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 this RFC.  I do not see any requests for changes to the proposed syntax extensions.  I agree that implementing these new feature in an edk2-staging branch makes a lot of sense.
 
Since Tim's request is about access to the SKU relationships from FW modules when the FW module executes, let's discuss this from an API perspective instead 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 SKU is related to other SKUs.  Those other modules can start with LibPcdGetSku() 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 file.  This derivative concept can be thought of as parent to child link between the 2 SKUs.  We can draw this visually as a tree with parent child relationships between all the SKUs.

Now from a module that calls LibPcdGetSku(), the module may want to know who the parent SKU is.  The information we have about the parent SKU is the SKU 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 the parent SKU.

So the request here is to extend the autogen to support a lookup of the parent SKU given any valid SKU ID value.

Thanks,

Mike
 
> -----Original Message-----
> From: Zeng, Star
> Sent: Friday, May 5, 2017 3:08 AM
> To: Tim Lewis <tim.lewis@insyde.com>; Kinney, Michael D 
> <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star 
> <star.zeng@intel.com>
> Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance
> 
> Tim,
> 
> In your code base, there are other tools beyond BaseTools to parse the 
> [SkuIds] section and SKUID_IDENTIFIER in DSC, right?
> 
> The boot time usage (use the value in DEFAULT SKU instead if the value 
> 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 
> 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 
> SKUID_IDENTIFIER_DEFAULT 2,1,0,1,0,0.
> 
> 
> The DSC syntax extension in this RFC is OPTIONAL, the backward 
> 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 
> of PCD related RFCs (include Structure PCD, etc). Mike and Liming can help confirm 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 <star.zeng@intel.com>; Kinney, Michael D 
> <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance
> 
> Star --
> 
> I understand your use case. We use the same behavior for other resources besides PCD.
> 
> All we are asking is that this data that is used by the build tools is 
> also available in some form at runtime.
> 
> Thanks,
> 
> Tim
> 
> 
> 
> -----Original Message-----
> From: Zeng, Star [mailto:star.zeng@intel.com]
> Sent: Thursday, May 04, 2017 6:42 AM
> To: Tim Lewis <tim.lewis@insyde.com>; Kinney, Michael D 
> <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star 
> <star.zeng@intel.com>
> 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) between non- DEFAULT SKUs, it seems easy to bring confusion from the proposed syntax "
> SkuValue|SkuName[|ParentSkuName]", especially the word 'Parent', sorry 
> SkuValue|for any
> confusion.
> The syntax extension proposed by this RFC is just to simplify the PCDs 
> configuring for multiple SKUs in DSC, I want to emphasize it is in 
> DSC, it is to cover the case that some non-DEFAULT SKU has much PCD 
> 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 
> the rule that DEFAULT SKU PCD value will be returned if the specified 
> SKU PCD value 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 = FALSE;
>   for (Index = 0; Index < SkuIdTable[0]; Index++) {
>     if (PeiPcdDb->SystemSkuId == SkuIdTable[Index + 1]) {
>       FoundSku = TRUE;
>       break;
>     }
>   }
> 
>   //
>   // Find the default SKU ID entry in SKU ID table.
>   //
>   if(!FoundSku) {
>     for (Index = 0; Index < SkuIdTable[0]; Index++) {
>       if (0 == SkuIdTable[Index + 1]) {
>         break;
>       }
>     }
>   }
> 
> 
> The usage case you provided for other resources beyond PCD could be like below?
> 
> CurrentSkuId = PcdGetSkuId();
> 
> Resource = NULL;
> if (!GetResourceForSkuId(CurrentSkuId, &Resource) {
>   // try DEFAULT SKU
>   GetResourceForSkuId(0, &Resource);
> }
> If (Resource == 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 <star.zeng@intel.com>; Kinney, Michael D 
> <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 resources. 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. We 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 
> yours exactly)
> 
> // Select which SKUs
> SKUID_IDENTIFIER = 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 
> other 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[] = {SKUID_IDENTIFIER_DEFAULT};
> UINT32 *SkuId;
> UINT32 CurrentSkuId;
> BOOLEAN Found;
> VOID *Resource;
> 
> CurrentSkuId = PcdGetSkuId();
> 
> SkuId = SkuIdDefaults;
> Found = (CurrentSkuId == 0); // so that DEFAULT will also return TRUE; 
> while (*SkuId != 0) {
>   if (*SkuId == CurrentSkuId) {
>     Found = TRUE;
>     Break;
>   }
>   while (*SkuId != 0) {
>      SkuId++;
>   }
>   SkuId++;
> }
> if (!Found) {
>   //error, because SKU ID was not found in array }
> 
> Resource = NULL;
> while (!GetResourceForSkuId(*SkuId, &Resource) && *SkuId == 0) {
>   *SkuId++;
> }
> If (Resource == 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 <tim.lewis@insyde.com>; Kinney, Michael D 
> <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star 
> <star.zeng@intel.com>
> 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 using [SkuIds] section and SKUID_IDENTIFIER for others beyond PCD?
> Then we can consider more in [RFC] PCD: Extended SKU support. Or do 
> you have 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; 
> Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Kinney, Michael D 
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; 
> Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
> 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 platform PEIM.
> 
> We should consider additional autogen that allows a module to 
> determine the relationships between SKUs.  This additional autogen is 
> not required for the 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>; 
> Kinney, Michael D 
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2- 
> devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; 
> Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
> Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance
> 
> 
> Start,
> 
> 
> 
> The RFC adds a new mechanism for expressing a relationship between 
> SKUs. The [SkuIds] section is not tied to PCDs.
> 
> 
> 
> 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 
> other places where such information can be used. Therefore, publishing 
> this information so that it can be used by other runtime agents 
> besides the. PCD 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<mailto:star.zeng@intel.com>
> Sent: Thursday, April 27, 2017 6:53 PM
> To: Tim Lewis<mailto:tim.lewis@insyde.com>; Kinney, Michael 
> D<mailto:michael.d.kinney@intel.com>; 
> edk2-devel@lists.01.org<mailto:edk2-
> devel@lists.01.org>
> Cc: Gao, Liming<mailto:liming.gao@intel.com>; Zeng, 
> Star<mailto:star.zeng@intel.com>
> 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 *simplify 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>; 
> Kinney, Michael D 
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2- 
> devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; 
> Kinney, Michael D 
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2- 
> devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; 
> Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
> 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 
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; 
> Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Kinney, Michael D 
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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
> > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; 
> > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>;
> > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> > devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D 
> > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > 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
> > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > Cc: Gao, Liming 
> > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>;
> > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; 
> > > edk2- devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, 
> > > Michael D 
> > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > Cc: Gao, Liming 
> > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > 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
> > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > Cc: Gao, Liming
> > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > 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 
> > > > <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>;
> > > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > > edk2- devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, 
> > > > Michael D 
> > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > Cc: Gao, Liming
> > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > 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
> > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>
> > > > > >; Zeng, Star 
> > > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > Cc: Gao, Liming
> > > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > 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
> > > > > <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, 
> > > > > Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> > > > > devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael 
> > > > > D 
> > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>
> > > > > >
> > > > > Cc: Gao, Liming
> > > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > 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
> > > > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > > Cc: Kinney, Michael D
> > > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.co
> > > > > > m>
> > > > > > >; Gao, Liming
> > > > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > > 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<mailto:edk2-devel@lists.01.org>
> > > > > > Cc: Kinney, Michael D
> > > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.co
> > > > > > m>
> > > > > > >; Zeng, Star
> > > > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Gao, 
> > > > > > Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > > 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<mailto:edk2-devel@lists.01.org>
> > > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > > > _______________________________________________
> > > > > > edk2-devel mailing list
> > > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > > _______________________________________________
> > > > > edk2-devel mailing list
> > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > _______________________________________________
> > > > edk2-devel mailing list
> > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > _______________________________________________
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > https://lists.01.org/mailman/listinfo/edk2-devel
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto: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

Re: [RFC] PCD: Extended SKU support 1 - inheritance

[Tim Lewis]

Star --

Thanks for your work on this. I have reviewed this and it looks good, addressing all of our concerns.

Tim

-----Original Message-----
From: Zeng, Star [mailto:star.zeng@intel.com] 
Sent: Monday, May 15, 2017 2:46 AM
To: Tim Lewis <tim.lewis@insyde.com>; Kinney, Michael D <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star <star.zeng@intel.com>
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-devel@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 = LibPcdGetSku ();

Resource = NULL;
while (!GetResourceForSkuId (SkuId, &Resource) && SkuId != 0) {
  SkuId = PcdGetParentSkuId (SkuId);
}
If (Resource == NULL) {
  // error, no resource found.
}


Thanks,
Star
-----Original Message-----
From: Kinney, Michael D
Sent: Saturday, May 6, 2017 12:07 AM
To: Zeng, Star <star.zeng@intel.com>; Tim Lewis <tim.lewis@insyde.com>; edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kinney@intel.com>
Cc: Gao, Liming <liming.gao@intel.com>
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 this RFC.  I do not see any requests for changes to the proposed syntax extensions.  I agree that implementing these new feature in an edk2-staging branch makes a lot of sense.
 
Since Tim's request is about access to the SKU relationships from FW modules when the FW module executes, let's discuss this from an API perspective instead 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 SKU is related to other SKUs.  Those other modules can start with LibPcdGetSku() 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 file.  This derivative concept can be thought of as parent to child link between the 2 SKUs.  We can draw this visually as a tree with parent child relationships between all the SKUs.

Now from a module that calls LibPcdGetSku(), the module may want to know who the parent SKU is.  The information we have about the parent SKU is the SKU 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 the parent SKU.

So the request here is to extend the autogen to support a lookup of the parent SKU given any valid SKU ID value.

Thanks,

Mike
 
> -----Original Message-----
> From: Zeng, Star
> Sent: Friday, May 5, 2017 3:08 AM
> To: Tim Lewis <tim.lewis@insyde.com>; Kinney, Michael D 
> <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star 
> <star.zeng@intel.com>
> Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance
> 
> Tim,
> 
> In your code base, there are other tools beyond BaseTools to parse the 
> [SkuIds] section and SKUID_IDENTIFIER in DSC, right?
> 
> The boot time usage (use the value in DEFAULT SKU instead if the value 
> 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 
> 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 
> SKUID_IDENTIFIER_DEFAULT 2,1,0,1,0,0.
> 
> 
> The DSC syntax extension in this RFC is OPTIONAL, the backward 
> 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 
> of PCD related RFCs (include Structure PCD, etc). Mike and Liming can help confirm 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 <star.zeng@intel.com>; Kinney, Michael D 
> <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> Subject: Re: [edk2] [RFC] PCD: Extended SKU support 1 - inheritance
> 
> Star --
> 
> I understand your use case. We use the same behavior for other resources besides PCD.
> 
> All we are asking is that this data that is used by the build tools is 
> also available in some form at runtime.
> 
> Thanks,
> 
> Tim
> 
> 
> 
> -----Original Message-----
> From: Zeng, Star [mailto:star.zeng@intel.com]
> Sent: Thursday, May 04, 2017 6:42 AM
> To: Tim Lewis <tim.lewis@insyde.com>; Kinney, Michael D 
> <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star 
> <star.zeng@intel.com>
> 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) between non- DEFAULT SKUs, it seems easy to bring confusion from the proposed syntax "
> SkuValue|SkuName[|ParentSkuName]", especially the word 'Parent', sorry 
> SkuValue|for any
> confusion.
> The syntax extension proposed by this RFC is just to simplify the PCDs 
> configuring for multiple SKUs in DSC, I want to emphasize it is in 
> DSC, it is to cover the case that some non-DEFAULT SKU has much PCD 
> 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 
> the rule that DEFAULT SKU PCD value will be returned if the specified 
> SKU PCD value 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 = FALSE;
>   for (Index = 0; Index < SkuIdTable[0]; Index++) {
>     if (PeiPcdDb->SystemSkuId == SkuIdTable[Index + 1]) {
>       FoundSku = TRUE;
>       break;
>     }
>   }
> 
>   //
>   // Find the default SKU ID entry in SKU ID table.
>   //
>   if(!FoundSku) {
>     for (Index = 0; Index < SkuIdTable[0]; Index++) {
>       if (0 == SkuIdTable[Index + 1]) {
>         break;
>       }
>     }
>   }
> 
> 
> The usage case you provided for other resources beyond PCD could be like below?
> 
> CurrentSkuId = PcdGetSkuId();
> 
> Resource = NULL;
> if (!GetResourceForSkuId(CurrentSkuId, &Resource) {
>   // try DEFAULT SKU
>   GetResourceForSkuId(0, &Resource);
> }
> If (Resource == 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 <star.zeng@intel.com>; Kinney, Michael D 
> <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> 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 resources. 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. We 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 
> yours exactly)
> 
> // Select which SKUs
> SKUID_IDENTIFIER = 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 
> other 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[] = {SKUID_IDENTIFIER_DEFAULT};
> UINT32 *SkuId;
> UINT32 CurrentSkuId;
> BOOLEAN Found;
> VOID *Resource;
> 
> CurrentSkuId = PcdGetSkuId();
> 
> SkuId = SkuIdDefaults;
> Found = (CurrentSkuId == 0); // so that DEFAULT will also return TRUE; 
> while (*SkuId != 0) {
>   if (*SkuId == CurrentSkuId) {
>     Found = TRUE;
>     Break;
>   }
>   while (*SkuId != 0) {
>      SkuId++;
>   }
>   SkuId++;
> }
> if (!Found) {
>   //error, because SKU ID was not found in array }
> 
> Resource = NULL;
> while (!GetResourceForSkuId(*SkuId, &Resource) && *SkuId == 0) {
>   *SkuId++;
> }
> If (Resource == 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 <tim.lewis@insyde.com>; Kinney, Michael D 
> <michael.d.kinney@intel.com>; edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>; Zeng, Star 
> <star.zeng@intel.com>
> 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 using [SkuIds] section and SKUID_IDENTIFIER for others beyond PCD?
> Then we can consider more in [RFC] PCD: Extended SKU support. Or do 
> you have 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>;
> Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Kinney, Michael D 
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>;
> Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
> 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 platform PEIM.
> 
> We should consider additional autogen that allows a module to 
> determine the relationships between SKUs.  This additional autogen is 
> not required for the 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> Kinney, Michael D
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2- 
> devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>;
> Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
> Subject: RE: [RFC] PCD: Extended SKU support 1 - inheritance
> 
> 
> Start,
> 
> 
> 
> The RFC adds a new mechanism for expressing a relationship between 
> SKUs. The [SkuIds] section is not tied to PCDs.
> 
> 
> 
> 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 
> other places where such information can be used. Therefore, publishing 
> this information so that it can be used by other runtime agents 
> besides the. PCD 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<mailto:star.zeng@intel.com>
> Sent: Thursday, April 27, 2017 6:53 PM
> To: Tim Lewis<mailto:tim.lewis@insyde.com>; Kinney, Michael 
> D<mailto:michael.d.kinney@intel.com>; 
> edk2-devel@lists.01.org<mailto:edk2-
> devel@lists.01.org>
> Cc: Gao, Liming<mailto:liming.gao@intel.com>; Zeng, 
> Star<mailto:star.zeng@intel.com>
> 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 *simplify 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 <star.zeng@intel.com<mailto:star.zeng@intel.com>>; 
> Kinney, Michael D 
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2- 
> devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; 
> Kinney, Michael D 
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; edk2- 
> devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>; 
> Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>
> 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 
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; 
> Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> devel@lists.01.org<mailto:edk2-devel@lists.01.org>; Kinney, Michael D 
> <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> 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
> > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; 
> > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>;
> > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> > devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael D 
> > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > Cc: Gao, Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > 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
> > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > Cc: Gao, Liming 
> > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > 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 <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>;
> > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; 
> > > edk2- devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, 
> > > Michael D 
> > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > Cc: Gao, Liming 
> > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > 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
> > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>;
> > > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > Cc: Gao, Liming
> > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > 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 
> > > > <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>;
> > > > Zeng, Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > > edk2- devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, 
> > > > Michael D 
> > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
> > > > Cc: Gao, Liming
> > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > 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
> > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>
> > > > > >; Zeng, Star 
> > > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > Cc: Gao, Liming
> > > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > 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
> > > > > <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>>; Zeng, 
> > > > > Star <star.zeng@intel.com<mailto:star.zeng@intel.com>>; edk2- 
> > > > > devel@lists.01.org<mailto:devel@lists.01.org>; Kinney, Michael 
> > > > > D 
> > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>
> > > > > >
> > > > > Cc: Gao, Liming
> > > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > 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
> > > > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>;
> > > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > > Cc: Kinney, Michael D
> > > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.co
> > > > > > m>
> > > > > > >; Gao, Liming
> > > > > > <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > > 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<mailto:edk2-devel@lists.01.org>
> > > > > > Cc: Kinney, Michael D
> > > > > > <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.co
> > > > > > m>
> > > > > > >; Zeng, Star
> > > > > > <star.zeng@intel.com<mailto:star.zeng@intel.com>>; Gao, 
> > > > > > Liming <liming.gao@intel.com<mailto:liming.gao@intel.com>>
> > > > > > 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<mailto:edk2-devel@lists.01.org>
> > > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > > > _______________________________________________
> > > > > > edk2-devel mailing list
> > > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > > _______________________________________________
> > > > > edk2-devel mailing list
> > > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > > _______________________________________________
> > > > edk2-devel mailing list
> > > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > > https://lists.01.org/mailman/listinfo/edk2-devel
> > > _______________________________________________
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > > https://lists.01.org/mailman/listinfo/edk2-devel
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
> > https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org<mailto: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