When we are writing the drivers for IP modules, then sometimes we want
that Platform specific customizations or platform dependent values be
supplied to IP module driver. normally we achieve this using Pcd values.

But sometimes we want to use header files for such data.e.g. if the
values are complex structures.

we need a mechanism that platform be able to supply these header files
to a module, without changing module code.

This patch is an attempt to achieve this functionality.

Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
---
 BaseTools/Source/Python/AutoGen/AutoGen.py | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py b/BaseTools/Source/Python/AutoGen/AutoGen.py
index 405bfa1..de4a17c 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -3783,6 +3783,18 @@ class ModuleAutoGen(AutoGen):
                 for Inc in IncludesList:
                     if Inc not in self._IncludePathList:
                         self._IncludePathList.append(str(Inc))
+            PackageFile = PathClass(os.path.join(self.PlatformInfo.MetaFile.SubDir, self.PlatformInfo.MetaFile.BaseName + '.dec'), self.PlatformInfo.MetaFile.Root)
+            Package = self.BuildDatabase[PackageFile, self.Arch, self.BuildTarget, self.ToolChain]
+            PackageDir = mws.join(self.WorkspaceDir, Package.MetaFile.Dir)
+            if PackageDir not in self._IncludePathList:
+                self._IncludePathList.append(PackageDir)
+            IncludesList = Package.Includes
+            if Package._PrivateIncludes:
+                if not self.MetaFile.Path.startswith(PackageDir):
+                    IncludesList = list(set(Package.Includes).difference(set(Package._PrivateIncludes)))
+            for Inc in IncludesList:
+                if Inc not in self._IncludePathList:
+                    self._IncludePathList.append(str(Inc))
         return self._IncludePathList
 
     def _GetIncludePathLength(self):
-- 
2.7.4

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

Hi,

Can you provide a simple example that shows how 
this feature is used and how it works?

Thanks,

Mike

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-
> bounces@lists.01.org] On Behalf Of Pankaj Bansal
> Sent: Sunday, February 25, 2018 10:29 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming <liming.gao@intel.com>
> Subject: [edk2] [RFC] Add Platform Include path in
> modules
> 
> When we are writing the drivers for IP modules, then
> sometimes we want
> that Platform specific customizations or platform
> dependent values be
> supplied to IP module driver. normally we achieve this
> using Pcd values.
> 
> But sometimes we want to use header files for such
> data.e.g. if the
> values are complex structures.
> 
> we need a mechanism that platform be able to supply
> these header files
> to a module, without changing module code.
> 
> This patch is an attempt to achieve this functionality.
> 
> Cc: Yonghong Zhu <yonghong.zhu@intel.com>
> Cc: Liming Gao <liming.gao@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
> ---
>  BaseTools/Source/Python/AutoGen/AutoGen.py | 12
> ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
> b/BaseTools/Source/Python/AutoGen/AutoGen.py
> index 405bfa1..de4a17c 100644
> --- a/BaseTools/Source/Python/AutoGen/AutoGen.py
> +++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
> @@ -3783,6 +3783,18 @@ class ModuleAutoGen(AutoGen):
>                  for Inc in IncludesList:
>                      if Inc not in
> self._IncludePathList:
> 
> self._IncludePathList.append(str(Inc))
> +            PackageFile =
> PathClass(os.path.join(self.PlatformInfo.MetaFile.SubDir
> , self.PlatformInfo.MetaFile.BaseName + '.dec'),
> self.PlatformInfo.MetaFile.Root)
> +            Package = self.BuildDatabase[PackageFile,
> self.Arch, self.BuildTarget, self.ToolChain]
> +            PackageDir = mws.join(self.WorkspaceDir,
> Package.MetaFile.Dir)
> +            if PackageDir not in self._IncludePathList:
> +
> self._IncludePathList.append(PackageDir)
> +            IncludesList = Package.Includes
> +            if Package._PrivateIncludes:
> +                if not
> self.MetaFile.Path.startswith(PackageDir):
> +                    IncludesList =
> list(set(Package.Includes).difference(set(Package._Priva
> teIncludes)))
> +            for Inc in IncludesList:
> +                if Inc not in self._IncludePathList:
> +
> self._IncludePathList.append(str(Inc))
>          return self._IncludePathList
> 
>      def _GetIncludePathLength(self):
> --
> 2.7.4
> 
> _______________________________________________
> 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

Hi,

Consider a simple driver which needs that some data structures be filled by the
Platform, which is using the driver.

Driver.c
#include <Platform.h>

Struct a = platformVal;

We can define platformVal in Platform.h, which would be unique to the platform being built.
This Platform.h can be placed in include directories, whose path would be defined in Platform.dec file.

Now, whenever we build driver for each unique platform, we need not to mention Platform.dec file in driver.inf [packages] section.
We can append Platform.dec include paths to each driver. i.e. look for the include files in [packages] section as well as in Platform include directories.

For this, I am looking for Platform.dec file in same directory as Platform.dsc and using same name as Platform.dsc

We can refine this change further. i.e. add Platform include directories to driver's include paths based on some condition in driver.inf file.

Thanks & Regards,
Pankaj Bansal

> -----Original Message-----
> From: Kinney, Michael D [mailto:michael.d.kinney@intel.com]
> Sent: Monday, February 26, 2018 1:13 PM
> To: Pankaj Bansal <pankaj.bansal@nxp.com>; edk2-devel@lists.01.org;
> Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: Gao, Liming <liming.gao@intel.com>
> Subject: RE: [edk2] [RFC] Add Platform Include path in modules
> 
> Hi,
> 
> Can you provide a simple example that shows how this feature is used and
> how it works?
> 
> Thanks,
> 
> Mike
> 
> > -----Original Message-----
> > From: edk2-devel [mailto:edk2-devel-
> > bounces@lists.01.org] On Behalf Of Pankaj Bansal
> > Sent: Sunday, February 25, 2018 10:29 PM
> > To: edk2-devel@lists.01.org
> > Cc: Gao, Liming <liming.gao@intel.com>
> > Subject: [edk2] [RFC] Add Platform Include path in modules
> >
> > When we are writing the drivers for IP modules, then sometimes we want
> > that Platform specific customizations or platform dependent values be
> > supplied to IP module driver. normally we achieve this using Pcd
> > values.
> >
> > But sometimes we want to use header files for such data.e.g. if the
> > values are complex structures.
> >
> > we need a mechanism that platform be able to supply these header files
> > to a module, without changing module code.
> >
> > This patch is an attempt to achieve this functionality.
> >
> > Cc: Yonghong Zhu <yonghong.zhu@intel.com>
> > Cc: Liming Gao <liming.gao@intel.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
> > ---
> >  BaseTools/Source/Python/AutoGen/AutoGen.py | 12
> > ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
> > b/BaseTools/Source/Python/AutoGen/AutoGen.py
> > index 405bfa1..de4a17c 100644
> > --- a/BaseTools/Source/Python/AutoGen/AutoGen.py
> > +++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
> > @@ -3783,6 +3783,18 @@ class ModuleAutoGen(AutoGen):
> >                  for Inc in IncludesList:
> >                      if Inc not in
> > self._IncludePathList:
> >
> > self._IncludePathList.append(str(Inc))
> > +            PackageFile =
> > PathClass(os.path.join(self.PlatformInfo.MetaFile.SubDir
> > , self.PlatformInfo.MetaFile.BaseName + '.dec'),
> > self.PlatformInfo.MetaFile.Root)
> > +            Package = self.BuildDatabase[PackageFile,
> > self.Arch, self.BuildTarget, self.ToolChain]
> > +            PackageDir = mws.join(self.WorkspaceDir,
> > Package.MetaFile.Dir)
> > +            if PackageDir not in self._IncludePathList:
> > +
> > self._IncludePathList.append(PackageDir)
> > +            IncludesList = Package.Includes
> > +            if Package._PrivateIncludes:
> > +                if not
> > self.MetaFile.Path.startswith(PackageDir):
> > +                    IncludesList =
> > list(set(Package.Includes).difference(set(Package._Priva
> > teIncludes)))
> > +            for Inc in IncludesList:
> > +                if Inc not in self._IncludePathList:
> > +
> > self._IncludePathList.append(str(Inc))
> >          return self._IncludePathList
> >
> >      def _GetIncludePathLength(self):
> > --
> > 2.7.4
> >
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
> > ts.01.org%2Fmailman%2Flistinfo%2Fedk2-
> devel&data=02%7C01%7Cpankaj.bans
> >
> al%40nxp.com%7Ccaec1b6b479b4111c26308d57cec86ac%7C686ea1d3bc2b4
> c6fa92c
> >
> d99c5c301635%7C0%7C0%7C636552277685045614&sdata=G3VP7FkkVcBKN4
> bkA5RRdJ
> > FzfpdIBhuxmRmBMcFvMY8%3D&reserved=0
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

On 02/26/18 11:55, Pankaj Bansal wrote:
> Hi,
> 
> Consider a simple driver which needs that some data structures be
> filled by the Platform, which is using the driver.
> 
> Driver.c #include <Platform.h>
> 
> Struct a = platformVal;
> 
> We can define platformVal in Platform.h, which would be unique to the
> platform being built. This Platform.h can be placed in include
> directories, whose path would be defined in Platform.dec file.
> 
> Now, whenever we build driver for each unique platform, we need not
> to mention Platform.dec file in driver.inf [packages] section. We can
> append Platform.dec include paths to each driver. i.e. look for the
> include files in [packages] section as well as in Platform include
> directories.
> 
> For this, I am looking for Platform.dec file in same directory as
> Platform.dsc and using same name as Platform.dsc
> 
> We can refine this change further. i.e. add Platform include
> directories to driver's include paths based on some condition in
> driver.inf file.

(Apologies in advance if I failed to grasp the use case.)

If I understand correctly, you have multiple platforms (defined by DSC
and FDF files), and you build a given driver for several of these
platforms, separately. And, when building the driver for the separate
platforms, you'd like the driver to get different initializers for
various static (global) structure variables.

Have you tried the structured PCD format? I think that could cover your
use case.

Unfortunately I couldn't find anything about structured PCDs in the edk2
specs, but there are several BZ references in the following mailing list
message:

[edk2] [Patch 00/14] Enable Structure PCD support in edk2

http://mid.mail-archive.com/1512140335-6932-1-git-send-email-liming.gao@intel.com

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

Hi Pankaj,

I agree with Laszlo that you should evaluate use of 
PCDs.  There are a few methods for a driver to use
platform specific values/behavior.  These are:

* PCDs
* Library class/Library Instance
* Protocol/PPI

One issue with the proposal is that it adds a hidden
dependency to modules.  An EDK II INF file describes
the external interfaces of a module along with
produces/consumes usage.  This information is aligned
with the XML schema that is documented in the UEFI
Platform Initialization Distribution Packaging Specification.

  http://uefi.org/specifications

If two modules have the same GUID/Version, then the external
interfaces to those two modules are expected to be identical.
With your proposal, two modules built for 2 different platforms
would have the same GUID/Version but would not have the same
external interfaces because a hidden dependency on a platform
package was added.

If a module really needs to use content from a platform
package, then a new copy of the module should be created
with a new GUID/Version and the platform package added to
the [Packages] section.  The other option is to use one
of the supported interfaces (PCDs, Lib, Protocol, PPI).

Please let us know if any of these exiting methods do not
work for your use case.

Thanks,

Mike

> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Monday, February 26, 2018 7:55 AM
> To: Pankaj Bansal <pankaj.bansal@nxp.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] Add Platform Include path in
> modules
> 
> On 02/26/18 11:55, Pankaj Bansal wrote:
> > Hi,
> >
> > Consider a simple driver which needs that some data
> structures be
> > filled by the Platform, which is using the driver.
> >
> > Driver.c #include <Platform.h>
> >
> > Struct a = platformVal;
> >
> > We can define platformVal in Platform.h, which would
> be unique to the
> > platform being built. This Platform.h can be placed in
> include
> > directories, whose path would be defined in
> Platform.dec file.
> >
> > Now, whenever we build driver for each unique
> platform, we need not
> > to mention Platform.dec file in driver.inf [packages]
> section. We can
> > append Platform.dec include paths to each driver. i.e.
> look for the
> > include files in [packages] section as well as in
> Platform include
> > directories.
> >
> > For this, I am looking for Platform.dec file in same
> directory as
> > Platform.dsc and using same name as Platform.dsc
> >
> > We can refine this change further. i.e. add Platform
> include
> > directories to driver's include paths based on some
> condition in
> > driver.inf file.
> 
> (Apologies in advance if I failed to grasp the use
> case.)
> 
> If I understand correctly, you have multiple platforms
> (defined by DSC
> and FDF files), and you build a given driver for several
> of these
> platforms, separately. And, when building the driver for
> the separate
> platforms, you'd like the driver to get different
> initializers for
> various static (global) structure variables.
> 
> Have you tried the structured PCD format? I think that
> could cover your
> use case.
> 
> Unfortunately I couldn't find anything about structured
> PCDs in the edk2
> specs, but there are several BZ references in the
> following mailing list
> message:
> 
> [edk2] [Patch 00/14] Enable Structure PCD support in
> edk2
> 
> http://mid.mail-archive.com/1512140335-6932-1-git-send-
> email-liming.gao@intel.com
> 
> Thanks
> Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Hi Laszlo/Michael,

Thanks for your feedback on this proposal.
I looked at the structured PCDs and UEFI Platform Initialization Distribution Packaging Specification.
Here is my take on these.

1. structured PCDs are good if we want to declare single complex structure.
    But consider a case where I want to keep device information in structure. (e.g. hardware settings, limitations etc)
    And we may want to tweak this information based on platform revision being used.
    And different platforms can have different number of such devices.
    In this case, when we want to add a new platform, we might need to introduce new PCDs in .dec files, which will not be needed for others.
    I don't know, will this even increase the PCD database size for existing platforms or not ?

2. To mitigate the "hidden" dependency of a module on platform, we can explicitly declare this dependency in module inf file.
     I am thinking something like gEfiCallerIdGuid, i.e. module can declare that that platform building(using) the module, supply this information.

3. Using Libraries and Protocols can also solve such use cases. I just felt that it's less cumbersome to use include files, and it also avoids code replication.
    Anyway, this is just my suggestion to have such mechanism in edk2 build process. I am more than happy to stick to platform libraries.

Thanks & Regards,
Pankaj Bansal

> -----Original Message-----
> From: Kinney, Michael D [mailto:michael.d.kinney@intel.com]
> Sent: Monday, February 26, 2018 10:56 PM
> To: Laszlo Ersek <lersek@redhat.com>; Pankaj Bansal
> <pankaj.bansal@nxp.com>; edk2-devel@lists.01.org; Kinney, Michael D
> <michael.d.kinney@intel.com>
> Cc: Gao, Liming <liming.gao@intel.com>
> Subject: RE: [edk2] [RFC] Add Platform Include path in modules
> 
> Hi Pankaj,
> 
> I agree with Laszlo that you should evaluate use of PCDs.  There are a few
> methods for a driver to use platform specific values/behavior.  These are:
> 
> * PCDs
> * Library class/Library Instance
> * Protocol/PPI
> 
> One issue with the proposal is that it adds a hidden dependency to modules.
> An EDK II INF file describes the external interfaces of a module along with
> produces/consumes usage.  This information is aligned with the XML schema
> that is documented in the UEFI Platform Initialization Distribution Packaging
> Specification.
> 
> 
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fuefi.
> org%2Fspecifications&data=02%7C01%7Cpankaj.bansal%40nxp.com%7C96c4
> 2dd7271d449d56e908d57d3df2d4%7C686ea1d3bc2b4c6fa92cd99c5c301635
> %7C0%7C0%7C636552627376357192&sdata=sS7KT3haANF5TLHSeRGjIQHnLQ
> BtnTDLIZWntUhsk78%3D&reserved=0
> 
> If two modules have the same GUID/Version, then the external interfaces to
> those two modules are expected to be identical.
> With your proposal, two modules built for 2 different platforms would have
> the same GUID/Version but would not have the same external interfaces
> because a hidden dependency on a platform package was added.
> 
> If a module really needs to use content from a platform package, then a new
> copy of the module should be created with a new GUID/Version and the
> platform package added to the [Packages] section.  The other option is to use
> one of the supported interfaces (PCDs, Lib, Protocol, PPI).
> 
> Please let us know if any of these exiting methods do not work for your use
> case.
> 
> Thanks,
> 
> Mike
> 
> > -----Original Message-----
> > From: Laszlo Ersek [mailto:lersek@redhat.com]
> > Sent: Monday, February 26, 2018 7:55 AM
> > To: Pankaj Bansal <pankaj.bansal@nxp.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] Add Platform Include path in modules
> >
> > On 02/26/18 11:55, Pankaj Bansal wrote:
> > > Hi,
> > >
> > > Consider a simple driver which needs that some data
> > structures be
> > > filled by the Platform, which is using the driver.
> > >
> > > Driver.c #include <Platform.h>
> > >
> > > Struct a = platformVal;
> > >
> > > We can define platformVal in Platform.h, which would
> > be unique to the
> > > platform being built. This Platform.h can be placed in
> > include
> > > directories, whose path would be defined in
> > Platform.dec file.
> > >
> > > Now, whenever we build driver for each unique
> > platform, we need not
> > > to mention Platform.dec file in driver.inf [packages]
> > section. We can
> > > append Platform.dec include paths to each driver. i.e.
> > look for the
> > > include files in [packages] section as well as in
> > Platform include
> > > directories.
> > >
> > > For this, I am looking for Platform.dec file in same
> > directory as
> > > Platform.dsc and using same name as Platform.dsc
> > >
> > > We can refine this change further. i.e. add Platform
> > include
> > > directories to driver's include paths based on some
> > condition in
> > > driver.inf file.
> >
> > (Apologies in advance if I failed to grasp the use
> > case.)
> >
> > If I understand correctly, you have multiple platforms (defined by DSC
> > and FDF files), and you build a given driver for several of these
> > platforms, separately. And, when building the driver for the separate
> > platforms, you'd like the driver to get different initializers for
> > various static (global) structure variables.
> >
> > Have you tried the structured PCD format? I think that could cover
> > your use case.
> >
> > Unfortunately I couldn't find anything about structured PCDs in the
> > edk2 specs, but there are several BZ references in the following
> > mailing list
> > message:
> >
> > [edk2] [Patch 00/14] Enable Structure PCD support in
> > edk2
> >
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmid.
> > mail-archive.com%2F1512140335-6932-1-git-send-
> &data=02%7C01%7Cpankaj.b
> >
> ansal%40nxp.com%7C96c42dd7271d449d56e908d57d3df2d4%7C686ea1d3b
> c2b4c6fa
> >
> 92cd99c5c301635%7C0%7C0%7C636552627376357192&sdata=iR50v%2F4Jg%
> 2BZQh7P
> > 1LB1bxeCryTangpA1SyVCwCEQW2U%3D&reserved=0
> > email-liming.gao@intel.com
> >
> > Thanks
> > Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Hi, 
  For the first one, the same PCD can be configured to the different value for the different SkuId. 

Here is wiki on structure pcd enable step and examples. 
https://github.com/lgao4/edk2/wiki/StructurePcd-Enable-Steps

TestPkg in https://github.com/lgao4/edk2/tree/UDK2018 has the sample case with structure pcd. 

Thanks
Liming
>-----Original Message-----
>From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
>Pankaj Bansal
>Sent: Tuesday, February 27, 2018 3:40 PM
>To: Kinney, Michael D <michael.d.kinney@intel.com>; Laszlo Ersek
><lersek@redhat.com>; edk2-devel@lists.01.org
>Cc: Gao, Liming <liming.gao@intel.com>
>Subject: Re: [edk2] [RFC] Add Platform Include path in modules
>
>Hi Laszlo/Michael,
>
>Thanks for your feedback on this proposal.
>I looked at the structured PCDs and UEFI Platform Initialization Distribution
>Packaging Specification.
>Here is my take on these.
>
>1. structured PCDs are good if we want to declare single complex structure.
>    But consider a case where I want to keep device information in structure.
>(e.g. hardware settings, limitations etc)
>    And we may want to tweak this information based on platform revision
>being used.
>    And different platforms can have different number of such devices.
>    In this case, when we want to add a new platform, we might need to
>introduce new PCDs in .dec files, which will not be needed for others.
>    I don't know, will this even increase the PCD database size for existing
>platforms or not ?
>
>2. To mitigate the "hidden" dependency of a module on platform, we can
>explicitly declare this dependency in module inf file.
>     I am thinking something like gEfiCallerIdGuid, i.e. module can declare that
>that platform building(using) the module, supply this information.
>
>3. Using Libraries and Protocols can also solve such use cases. I just felt that it's
>less cumbersome to use include files, and it also avoids code replication.
>    Anyway, this is just my suggestion to have such mechanism in edk2 build
>process. I am more than happy to stick to platform libraries.
>
>Thanks & Regards,
>Pankaj Bansal
>
>> -----Original Message-----
>> From: Kinney, Michael D [mailto:michael.d.kinney@intel.com]
>> Sent: Monday, February 26, 2018 10:56 PM
>> To: Laszlo Ersek <lersek@redhat.com>; Pankaj Bansal
>> <pankaj.bansal@nxp.com>; edk2-devel@lists.01.org; Kinney, Michael D
>> <michael.d.kinney@intel.com>
>> Cc: Gao, Liming <liming.gao@intel.com>
>> Subject: RE: [edk2] [RFC] Add Platform Include path in modules
>>
>> Hi Pankaj,
>>
>> I agree with Laszlo that you should evaluate use of PCDs.  There are a few
>> methods for a driver to use platform specific values/behavior.  These are:
>>
>> * PCDs
>> * Library class/Library Instance
>> * Protocol/PPI
>>
>> One issue with the proposal is that it adds a hidden dependency to modules.
>> An EDK II INF file describes the external interfaces of a module along with
>> produces/consumes usage.  This information is aligned with the XML
>schema
>> that is documented in the UEFI Platform Initialization Distribution Packaging
>> Specification.
>>
>>
>>
>https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fuefi.
>>
>org%2Fspecifications&data=02%7C01%7Cpankaj.bansal%40nxp.com%7C96c4
>> 2dd7271d449d56e908d57d3df2d4%7C686ea1d3bc2b4c6fa92cd99c5c301635
>> %7C0%7C0%7C636552627376357192&sdata=sS7KT3haANF5TLHSeRGjIQHnLQ
>> BtnTDLIZWntUhsk78%3D&reserved=0
>>
>> If two modules have the same GUID/Version, then the external interfaces
>to
>> those two modules are expected to be identical.
>> With your proposal, two modules built for 2 different platforms would have
>> the same GUID/Version but would not have the same external interfaces
>> because a hidden dependency on a platform package was added.
>>
>> If a module really needs to use content from a platform package, then a
>new
>> copy of the module should be created with a new GUID/Version and the
>> platform package added to the [Packages] section.  The other option is to
>use
>> one of the supported interfaces (PCDs, Lib, Protocol, PPI).
>>
>> Please let us know if any of these exiting methods do not work for your use
>> case.
>>
>> Thanks,
>>
>> Mike
>>
>> > -----Original Message-----
>> > From: Laszlo Ersek [mailto:lersek@redhat.com]
>> > Sent: Monday, February 26, 2018 7:55 AM
>> > To: Pankaj Bansal <pankaj.bansal@nxp.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] Add Platform Include path in modules
>> >
>> > On 02/26/18 11:55, Pankaj Bansal wrote:
>> > > Hi,
>> > >
>> > > Consider a simple driver which needs that some data
>> > structures be
>> > > filled by the Platform, which is using the driver.
>> > >
>> > > Driver.c #include <Platform.h>
>> > >
>> > > Struct a = platformVal;
>> > >
>> > > We can define platformVal in Platform.h, which would
>> > be unique to the
>> > > platform being built. This Platform.h can be placed in
>> > include
>> > > directories, whose path would be defined in
>> > Platform.dec file.
>> > >
>> > > Now, whenever we build driver for each unique
>> > platform, we need not
>> > > to mention Platform.dec file in driver.inf [packages]
>> > section. We can
>> > > append Platform.dec include paths to each driver. i.e.
>> > look for the
>> > > include files in [packages] section as well as in
>> > Platform include
>> > > directories.
>> > >
>> > > For this, I am looking for Platform.dec file in same
>> > directory as
>> > > Platform.dsc and using same name as Platform.dsc
>> > >
>> > > We can refine this change further. i.e. add Platform
>> > include
>> > > directories to driver's include paths based on some
>> > condition in
>> > > driver.inf file.
>> >
>> > (Apologies in advance if I failed to grasp the use
>> > case.)
>> >
>> > If I understand correctly, you have multiple platforms (defined by DSC
>> > and FDF files), and you build a given driver for several of these
>> > platforms, separately. And, when building the driver for the separate
>> > platforms, you'd like the driver to get different initializers for
>> > various static (global) structure variables.
>> >
>> > Have you tried the structured PCD format? I think that could cover
>> > your use case.
>> >
>> > Unfortunately I couldn't find anything about structured PCDs in the
>> > edk2 specs, but there are several BZ references in the following
>> > mailing list
>> > message:
>> >
>> > [edk2] [Patch 00/14] Enable Structure PCD support in
>> > edk2
>> >
>> >
>>
>https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmid.
>> > mail-archive.com%2F1512140335-6932-1-git-send-
>> &data=02%7C01%7Cpankaj.b
>> >
>> ansal%40nxp.com%7C96c42dd7271d449d56e908d57d3df2d4%7C686ea1d3b
>> c2b4c6fa
>> >
>> 92cd99c5c301635%7C0%7C0%7C636552627376357192&sdata=iR50v%2F4Jg%
>> 2BZQh7P
>> > 1LB1bxeCryTangpA1SyVCwCEQW2U%3D&reserved=0
>> > email-liming.gao@intel.com
>> >
>> > Thanks
>> > Laszlo
>_______________________________________________
>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

Hi All,

Will It violate the UEFI Platform Initialization Distribution Packaging Specification if we want to use Computed Includes ?
https://gcc.gnu.org/onlinedocs/gcc-3.0.2/cpp_2.html#SEC10

Thanks & Regards,
Pankaj Bansal

> -----Original Message-----
> From: Gao, Liming [mailto:liming.gao@intel.com]
> Sent: Tuesday, February 27, 2018 4:52 PM
> To: Pankaj Bansal <pankaj.bansal@nxp.com>; Kinney, Michael D
> <michael.d.kinney@intel.com>; Laszlo Ersek <lersek@redhat.com>; edk2-
> devel@lists.01.org
> Subject: RE: [edk2] [RFC] Add Platform Include path in modules
> 
> Hi,
>   For the first one, the same PCD can be configured to the different value for
> the different SkuId.
> 
> Here is wiki on structure pcd enable step and examples.
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Flgao4%2Fedk2%2Fwiki%2FStructurePcd-Enable-
> Steps&data=02%7C01%7Cpankaj.bansal%40nxp.com%7C613339ac821e4bcc9
> fd508d57dd44781%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6
> 36553273075487313&sdata=DNiyfbhwN%2BKdFkltL%2FQQTzWFc8hhnNsXbC
> 4KjIHUy%2Bs%3D&reserved=0
> 
> TestPkg in
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Flgao4%2Fedk2%2Ftree%2FUDK2018&data=02%7C01%7Cpankaj.b
> ansal%40nxp.com%7C613339ac821e4bcc9fd508d57dd44781%7C686ea1d3bc
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C636553273075487313&sdata=8aBhP
> vNDkt%2FPb2kmAEXz0gERW9MFGD3kt8YcvjGi7jc%3D&reserved=0 has the
> sample case with structure pcd.
> 
> Thanks
> Liming
> >-----Original Message-----
> >From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> >Pankaj Bansal
> >Sent: Tuesday, February 27, 2018 3:40 PM
> >To: Kinney, Michael D <michael.d.kinney@intel.com>; Laszlo Ersek
> ><lersek@redhat.com>; edk2-devel@lists.01.org
> >Cc: Gao, Liming <liming.gao@intel.com>
> >Subject: Re: [edk2] [RFC] Add Platform Include path in modules
> >
> >Hi Laszlo/Michael,
> >
> >Thanks for your feedback on this proposal.
> >I looked at the structured PCDs and UEFI Platform Initialization
> >Distribution Packaging Specification.
> >Here is my take on these.
> >
> >1. structured PCDs are good if we want to declare single complex structure.
> >    But consider a case where I want to keep device information in structure.
> >(e.g. hardware settings, limitations etc)
> >    And we may want to tweak this information based on platform
> >revision being used.
> >    And different platforms can have different number of such devices.
> >    In this case, when we want to add a new platform, we might need to
> >introduce new PCDs in .dec files, which will not be needed for others.
> >    I don't know, will this even increase the PCD database size for
> >existing platforms or not ?
> >
> >2. To mitigate the "hidden" dependency of a module on platform, we can
> >explicitly declare this dependency in module inf file.
> >     I am thinking something like gEfiCallerIdGuid, i.e. module can
> >declare that that platform building(using) the module, supply this
> information.
> >
> >3. Using Libraries and Protocols can also solve such use cases. I just
> >felt that it's less cumbersome to use include files, and it also avoids code
> replication.
> >    Anyway, this is just my suggestion to have such mechanism in edk2
> >build process. I am more than happy to stick to platform libraries.
> >
> >Thanks & Regards,
> >Pankaj Bansal
> >
> >> -----Original Message-----
> >> From: Kinney, Michael D [mailto:michael.d.kinney@intel.com]
> >> Sent: Monday, February 26, 2018 10:56 PM
> >> To: Laszlo Ersek <lersek@redhat.com>; Pankaj Bansal
> >> <pankaj.bansal@nxp.com>; edk2-devel@lists.01.org; Kinney, Michael D
> >> <michael.d.kinney@intel.com>
> >> Cc: Gao, Liming <liming.gao@intel.com>
> >> Subject: RE: [edk2] [RFC] Add Platform Include path in modules
> >>
> >> Hi Pankaj,
> >>
> >> I agree with Laszlo that you should evaluate use of PCDs.  There are
> >> a few methods for a driver to use platform specific values/behavior.
> These are:
> >>
> >> * PCDs
> >> * Library class/Library Instance
> >> * Protocol/PPI
> >>
> >> One issue with the proposal is that it adds a hidden dependency to
> modules.
> >> An EDK II INF file describes the external interfaces of a module
> >> along with produces/consumes usage.  This information is aligned with
> >> the XML
> >schema
> >> that is documented in the UEFI Platform Initialization Distribution
> >> Packaging Specification.
> >>
> >>
> >>
> >https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fuefi
> .
> >>
> >org%2Fspecifications&data=02%7C01%7Cpankaj.bansal%40nxp.com%7C96c
> 4
> >>
> 2dd7271d449d56e908d57d3df2d4%7C686ea1d3bc2b4c6fa92cd99c5c301635
> >>
> %7C0%7C0%7C636552627376357192&sdata=sS7KT3haANF5TLHSeRGjIQHnLQ
> >> BtnTDLIZWntUhsk78%3D&reserved=0
> >>
> >> If two modules have the same GUID/Version, then the external
> >> interfaces
> >to
> >> those two modules are expected to be identical.
> >> With your proposal, two modules built for 2 different platforms would
> >> have the same GUID/Version but would not have the same external
> >> interfaces because a hidden dependency on a platform package was
> added.
> >>
> >> If a module really needs to use content from a platform package, then
> >> a
> >new
> >> copy of the module should be created with a new GUID/Version and the
> >> platform package added to the [Packages] section.  The other option
> >> is to
> >use
> >> one of the supported interfaces (PCDs, Lib, Protocol, PPI).
> >>
> >> Please let us know if any of these exiting methods do not work for
> >> your use case.
> >>
> >> Thanks,
> >>
> >> Mike
> >>
> >> > -----Original Message-----
> >> > From: Laszlo Ersek [mailto:lersek@redhat.com]
> >> > Sent: Monday, February 26, 2018 7:55 AM
> >> > To: Pankaj Bansal <pankaj.bansal@nxp.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] Add Platform Include path in modules
> >> >
> >> > On 02/26/18 11:55, Pankaj Bansal wrote:
> >> > > Hi,
> >> > >
> >> > > Consider a simple driver which needs that some data
> >> > structures be
> >> > > filled by the Platform, which is using the driver.
> >> > >
> >> > > Driver.c #include <Platform.h>
> >> > >
> >> > > Struct a = platformVal;
> >> > >
> >> > > We can define platformVal in Platform.h, which would
> >> > be unique to the
> >> > > platform being built. This Platform.h can be placed in
> >> > include
> >> > > directories, whose path would be defined in
> >> > Platform.dec file.
> >> > >
> >> > > Now, whenever we build driver for each unique
> >> > platform, we need not
> >> > > to mention Platform.dec file in driver.inf [packages]
> >> > section. We can
> >> > > append Platform.dec include paths to each driver. i.e.
> >> > look for the
> >> > > include files in [packages] section as well as in
> >> > Platform include
> >> > > directories.
> >> > >
> >> > > For this, I am looking for Platform.dec file in same
> >> > directory as
> >> > > Platform.dsc and using same name as Platform.dsc
> >> > >
> >> > > We can refine this change further. i.e. add Platform
> >> > include
> >> > > directories to driver's include paths based on some
> >> > condition in
> >> > > driver.inf file.
> >> >
> >> > (Apologies in advance if I failed to grasp the use
> >> > case.)
> >> >
> >> > If I understand correctly, you have multiple platforms (defined by
> >> > DSC and FDF files), and you build a given driver for several of
> >> > these platforms, separately. And, when building the driver for the
> >> > separate platforms, you'd like the driver to get different
> >> > initializers for various static (global) structure variables.
> >> >
> >> > Have you tried the structured PCD format? I think that could cover
> >> > your use case.
> >> >
> >> > Unfortunately I couldn't find anything about structured PCDs in the
> >> > edk2 specs, but there are several BZ references in the following
> >> > mailing list
> >> > message:
> >> >
> >> > [edk2] [Patch 00/14] Enable Structure PCD support in
> >> > edk2
> >> >
> >> >
> >>
> >https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmid
> .
> >> > mail-archive.com%2F1512140335-6932-1-git-send-
> >> &data=02%7C01%7Cpankaj.b
> >> >
> >>
> ansal%40nxp.com%7C96c42dd7271d449d56e908d57d3df2d4%7C686ea1d3b
> >> c2b4c6fa
> >> >
> >>
> 92cd99c5c301635%7C0%7C0%7C636552627376357192&sdata=iR50v%2F4Jg%
> >> 2BZQh7P
> >> > 1LB1bxeCryTangpA1SyVCwCEQW2U%3D&reserved=0
> >> > email-liming.gao@intel.com
> >> >
> >> > Thanks
> >> > Laszlo
> >_______________________________________________
> >edk2-devel mailing list
> >edk2-devel@lists.01.org
> >https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> >s.01.org%2Fmailman%2Flistinfo%2Fedk2-
> devel&data=02%7C01%7Cpankaj.bansal
> >%40nxp.com%7C613339ac821e4bcc9fd508d57dd44781%7C686ea1d3bc2b4
> c6fa92cd99
> >c5c301635%7C0%7C0%7C636553273075487313&sdata=CFicYp1LfCJDNiy1BV
> QHssZPLY
> >YT3bG6odDjBADql8I%3D&reserved=0
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Pankaj Bansal,

Computed includes are really just a shorthand for #if
statements around #include statements.

These statements appear in the C code to a module.  As
long as all the platform packages that the include file
might be included from are listed in the [Packages]
section of the INF file for that module, then it is
compatible with UDP.

From a UDP perspective, this means that the package with 
the more generic module cannot be installed until all
the dependent platform packages have been installed.  If
you add support for more platforms, then you have to add
platform packages to the [Packages] section of the more
generic module.

This dependency is the reverse of what we prefer.  We
prefer to have platform packages depend on more generic
packages, so the more generic packages can be installed
first without dependencies on any specific platform
package.

Mike

> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-
> bounces@lists.01.org] On Behalf Of Pankaj Bansal
> Sent: Friday, March 9, 2018 2:54 AM
> To: Gao, Liming <liming.gao@intel.com>; Kinney, Michael
> D <michael.d.kinney@intel.com>; Laszlo Ersek
> <lersek@redhat.com>; edk2-devel@lists.01.org
> Subject: Re: [edk2] [RFC] Add Platform Include path in
> modules
> 
> Hi All,
> 
> Will It violate the UEFI Platform Initialization
> Distribution Packaging Specification if we want to use
> Computed Includes ?
> https://gcc.gnu.org/onlinedocs/gcc-
> 3.0.2/cpp_2.html#SEC10
> 
> Thanks & Regards,
> Pankaj Bansal
> 
> > -----Original Message-----
> > From: Gao, Liming [mailto:liming.gao@intel.com]
> > Sent: Tuesday, February 27, 2018 4:52 PM
> > To: Pankaj Bansal <pankaj.bansal@nxp.com>; Kinney,
> Michael D
> > <michael.d.kinney@intel.com>; Laszlo Ersek
> <lersek@redhat.com>; edk2-
> > devel@lists.01.org
> > Subject: RE: [edk2] [RFC] Add Platform Include path in
> modules
> >
> > Hi,
> >   For the first one, the same PCD can be configured to
> the different value for
> > the different SkuId.
> >
> > Here is wiki on structure pcd enable step and
> examples.
> >
> https://emea01.safelinks.protection.outlook.com/?url=htt
> ps%3A%2F%2Fgith
> > ub.com%2Flgao4%2Fedk2%2Fwiki%2FStructurePcd-Enable-
> >
> Steps&data=02%7C01%7Cpankaj.bansal%40nxp.com%7C613339ac8
> 21e4bcc9
> >
> fd508d57dd44781%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7
> C0%7C6
> >
> 36553273075487313&sdata=DNiyfbhwN%2BKdFkltL%2FQQTzWFc8hh
> nNsXbC
> > 4KjIHUy%2Bs%3D&reserved=0
> >
> > TestPkg in
> >
> https://emea01.safelinks.protection.outlook.com/?url=htt
> ps%3A%2F%2Fgith
> >
> ub.com%2Flgao4%2Fedk2%2Ftree%2FUDK2018&data=02%7C01%7Cpa
> nkaj.b
> >
> ansal%40nxp.com%7C613339ac821e4bcc9fd508d57dd44781%7C686
> ea1d3bc
> >
> 2b4c6fa92cd99c5c301635%7C0%7C0%7C636553273075487313&sdat
> a=8aBhP
> > vNDkt%2FPb2kmAEXz0gERW9MFGD3kt8YcvjGi7jc%3D&reserved=0
> has the
> > sample case with structure pcd.
> >
> > Thanks
> > Liming
> > >-----Original Message-----
> > >From: edk2-devel [mailto:edk2-devel-
> bounces@lists.01.org] On Behalf Of
> > >Pankaj Bansal
> > >Sent: Tuesday, February 27, 2018 3:40 PM
> > >To: Kinney, Michael D <michael.d.kinney@intel.com>;
> Laszlo Ersek
> > ><lersek@redhat.com>; edk2-devel@lists.01.org
> > >Cc: Gao, Liming <liming.gao@intel.com>
> > >Subject: Re: [edk2] [RFC] Add Platform Include path
> in modules
> > >
> > >Hi Laszlo/Michael,
> > >
> > >Thanks for your feedback on this proposal.
> > >I looked at the structured PCDs and UEFI Platform
> Initialization
> > >Distribution Packaging Specification.
> > >Here is my take on these.
> > >
> > >1. structured PCDs are good if we want to declare
> single complex structure.
> > >    But consider a case where I want to keep device
> information in structure.
> > >(e.g. hardware settings, limitations etc)
> > >    And we may want to tweak this information based
> on platform
> > >revision being used.
> > >    And different platforms can have different number
> of such devices.
> > >    In this case, when we want to add a new platform,
> we might need to
> > >introduce new PCDs in .dec files, which will not be
> needed for others.
> > >    I don't know, will this even increase the PCD
> database size for
> > >existing platforms or not ?
> > >
> > >2. To mitigate the "hidden" dependency of a module on
> platform, we can
> > >explicitly declare this dependency in module inf
> file.
> > >     I am thinking something like gEfiCallerIdGuid,
> i.e. module can
> > >declare that that platform building(using) the
> module, supply this
> > information.
> > >
> > >3. Using Libraries and Protocols can also solve such
> use cases. I just
> > >felt that it's less cumbersome to use include files,
> and it also avoids code
> > replication.
> > >    Anyway, this is just my suggestion to have such
> mechanism in edk2
> > >build process. I am more than happy to stick to
> platform libraries.
> > >
> > >Thanks & Regards,
> > >Pankaj Bansal
> > >
> > >> -----Original Message-----
> > >> From: Kinney, Michael D
> [mailto:michael.d.kinney@intel.com]
> > >> Sent: Monday, February 26, 2018 10:56 PM
> > >> To: Laszlo Ersek <lersek@redhat.com>; Pankaj Bansal
> > >> <pankaj.bansal@nxp.com>; edk2-devel@lists.01.org;
> Kinney, Michael D
> > >> <michael.d.kinney@intel.com>
> > >> Cc: Gao, Liming <liming.gao@intel.com>
> > >> Subject: RE: [edk2] [RFC] Add Platform Include path
> in modules
> > >>
> > >> Hi Pankaj,
> > >>
> > >> I agree with Laszlo that you should evaluate use of
> PCDs.  There are
> > >> a few methods for a driver to use platform specific
> values/behavior.
> > These are:
> > >>
> > >> * PCDs
> > >> * Library class/Library Instance
> > >> * Protocol/PPI
> > >>
> > >> One issue with the proposal is that it adds a
> hidden dependency to
> > modules.
> > >> An EDK II INF file describes the external
> interfaces of a module
> > >> along with produces/consumes usage.  This
> information is aligned with
> > >> the XML
> > >schema
> > >> that is documented in the UEFI Platform
> Initialization Distribution
> > >> Packaging Specification.
> > >>
> > >>
> > >>
> >
> >https://emea01.safelinks.protection.outlook.com/?url=ht
> tp%3A%2F%2Fuefi
> > .
> > >>
> >
> >org%2Fspecifications&data=02%7C01%7Cpankaj.bansal%40nxp
> .com%7C96c
> > 4
> > >>
> >
> 2dd7271d449d56e908d57d3df2d4%7C686ea1d3bc2b4c6fa92cd99c5
> c301635
> > >>
> >
> %7C0%7C0%7C636552627376357192&sdata=sS7KT3haANF5TLHSeRGj
> IQHnLQ
> > >> BtnTDLIZWntUhsk78%3D&reserved=0
> > >>
> > >> If two modules have the same GUID/Version, then the
> external
> > >> interfaces
> > >to
> > >> those two modules are expected to be identical.
> > >> With your proposal, two modules built for 2
> different platforms would
> > >> have the same GUID/Version but would not have the
> same external
> > >> interfaces because a hidden dependency on a
> platform package was
> > added.
> > >>
> > >> If a module really needs to use content from a
> platform package, then
> > >> a
> > >new
> > >> copy of the module should be created with a new
> GUID/Version and the
> > >> platform package added to the [Packages] section.
> The other option
> > >> is to
> > >use
> > >> one of the supported interfaces (PCDs, Lib,
> Protocol, PPI).
> > >>
> > >> Please let us know if any of these exiting methods
> do not work for
> > >> your use case.
> > >>
> > >> Thanks,
> > >>
> > >> Mike
> > >>
> > >> > -----Original Message-----
> > >> > From: Laszlo Ersek [mailto:lersek@redhat.com]
> > >> > Sent: Monday, February 26, 2018 7:55 AM
> > >> > To: Pankaj Bansal <pankaj.bansal@nxp.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] Add Platform Include
> path in modules
> > >> >
> > >> > On 02/26/18 11:55, Pankaj Bansal wrote:
> > >> > > Hi,
> > >> > >
> > >> > > Consider a simple driver which needs that some
> data
> > >> > structures be
> > >> > > filled by the Platform, which is using the
> driver.
> > >> > >
> > >> > > Driver.c #include <Platform.h>
> > >> > >
> > >> > > Struct a = platformVal;
> > >> > >
> > >> > > We can define platformVal in Platform.h, which
> would
> > >> > be unique to the
> > >> > > platform being built. This Platform.h can be
> placed in
> > >> > include
> > >> > > directories, whose path would be defined in
> > >> > Platform.dec file.
> > >> > >
> > >> > > Now, whenever we build driver for each unique
> > >> > platform, we need not
> > >> > > to mention Platform.dec file in driver.inf
> [packages]
> > >> > section. We can
> > >> > > append Platform.dec include paths to each
> driver. i.e.
> > >> > look for the
> > >> > > include files in [packages] section as well as
> in
> > >> > Platform include
> > >> > > directories.
> > >> > >
> > >> > > For this, I am looking for Platform.dec file in
> same
> > >> > directory as
> > >> > > Platform.dsc and using same name as
> Platform.dsc
> > >> > >
> > >> > > We can refine this change further. i.e. add
> Platform
> > >> > include
> > >> > > directories to driver's include paths based on
> some
> > >> > condition in
> > >> > > driver.inf file.
> > >> >
> > >> > (Apologies in advance if I failed to grasp the
> use
> > >> > case.)
> > >> >
> > >> > If I understand correctly, you have multiple
> platforms (defined by
> > >> > DSC and FDF files), and you build a given driver
> for several of
> > >> > these platforms, separately. And, when building
> the driver for the
> > >> > separate platforms, you'd like the driver to get
> different
> > >> > initializers for various static (global)
> structure variables.
> > >> >
> > >> > Have you tried the structured PCD format? I think
> that could cover
> > >> > your use case.
> > >> >
> > >> > Unfortunately I couldn't find anything about
> structured PCDs in the
> > >> > edk2 specs, but there are several BZ references
> in the following
> > >> > mailing list
> > >> > message:
> > >> >
> > >> > [edk2] [Patch 00/14] Enable Structure PCD support
> in
> > >> > edk2
> > >> >
> > >> >
> > >>
> >
> >https://emea01.safelinks.protection.outlook.com/?url=ht
> tp%3A%2F%2Fmid
> > .
> > >> > mail-archive.com%2F1512140335-6932-1-git-send-
> > >> &data=02%7C01%7Cpankaj.b
> > >> >
> > >>
> >
> ansal%40nxp.com%7C96c42dd7271d449d56e908d57d3df2d4%7C686
> ea1d3b
> > >> c2b4c6fa
> > >> >
> > >>
> >
> 92cd99c5c301635%7C0%7C0%7C636552627376357192&sdata=iR50v
> %2F4Jg%
> > >> 2BZQh7P
> > >> > 1LB1bxeCryTangpA1SyVCwCEQW2U%3D&reserved=0
> > >> > email-liming.gao@intel.com
> > >> >
> > >> > Thanks
> > >> > Laszlo
> > >_______________________________________________
> > >edk2-devel mailing list
> > >edk2-devel@lists.01.org
> >
> >https://emea01.safelinks.protection.outlook.com/?url=ht
> tps%3A%2F%2Flist
> > >s.01.org%2Fmailman%2Flistinfo%2Fedk2-
> > devel&data=02%7C01%7Cpankaj.bansal
> >
> >%40nxp.com%7C613339ac821e4bcc9fd508d57dd44781%7C686ea1d
> 3bc2b4
> > c6fa92cd99
> >
> >c5c301635%7C0%7C0%7C636553273075487313&sdata=CFicYp1LfC
> JDNiy1BV
> > QHssZPLY
> > >YT3bG6odDjBADql8I%3D&reserved=0
> _______________________________________________
> 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

When we are writing the drivers for IP modules, then sometimes we want
that Platform specific customizations or platform dependent values be
supplied to IP module driver. normally we achieve this using Pcd values.

But sometimes we want to use header files for such data.e.g. if the
values are complex structures.

we need a mechanism that platform be able to supply these header files
to a module, without changing module code.

This patch is an attempt to achieve this functionality.

Cc: Yonghong Zhu <yonghong.zhu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
---

Notes:
    V2:
     -check if .dec file exist before appending include paths to include path list

 BaseTools/Source/Python/AutoGen/AutoGen.py | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py b/BaseTools/Source/Python/AutoGen/AutoGen.py
index 405bfa1..4b281d8 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -3783,6 +3783,20 @@ class ModuleAutoGen(AutoGen):
                 for Inc in IncludesList:
                     if Inc not in self._IncludePathList:
                         self._IncludePathList.append(str(Inc))
+            PackageFilePath = os.path.join(self.PlatformInfo.MetaFile.SubDir, self.PlatformInfo.MetaFile.BaseName + '.dec')
+            if os.path.isfile(os.path.normpath(mws.join(self.PlatformInfo.MetaFile.Root, PackageFilePath))):
+                PackageFile = PathClass(PackageFilePath, self.PlatformInfo.MetaFile.Root)
+                Package = self.BuildDatabase[PackageFile, self.Arch, self.BuildTarget, self.ToolChain]
+                PackageDir = mws.join(self.WorkspaceDir, Package.MetaFile.Dir)
+                if PackageDir not in self._IncludePathList:
+                    self._IncludePathList.append(PackageDir)
+                IncludesList = Package.Includes
+                if Package._PrivateIncludes:
+                    if not self.MetaFile.Path.startswith(PackageDir):
+                        IncludesList = list(set(Package.Includes).difference(set(Package._PrivateIncludes)))
+                for Inc in IncludesList:
+                    if Inc not in self._IncludePathList:
+                        self._IncludePathList.append(str(Inc))
         return self._IncludePathList
 
     def _GetIncludePathLength(self):
-- 
2.7.4

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