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:[email protected]]
> Sent: Monday, February 26, 2018 7:55 AM
> To: Pankaj Bansal <[email protected]>; Kinney,
> Michael D <[email protected]>; edk2-
> [email protected]
> Cc: Gao, Liming <[email protected]>
> 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 protected]
> 
> Thanks
> Laszlo
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel

Reply via email to