On Jan 31, 2013, at 12:05 PM, "David F." <[email protected]> wrote:
> Thanks Mike. That leads me to the next point of confusion. Is the purpose
> of the Platform Configuration Database (PCD) to share variables across
> drivers, applications, and/or whatever is launching an app or driver; or is
> it just a method the build system offers for you to define variables in a
> configuration file instead of a .h header file?
>
There were a couple of requirements for the edk2 that ended up turning into
PCD.
1) Config knobs for a driver need to be configurable by the platform so that
they could be setup options (Hii), or constants, or SKU defined, programmed in
the factory (VPD), etc.
2) We needed a mechanism to support patching config values into a binary, and a
runtime mechanism to configure a binary module.
Both Mike and I hated code bases with large numbers of #ifdefs to turn stuff on
and off because in our experience code will rot out in some of the #ifdef paths
and make the entire thing very hard to maintain.
It was also the vision that chip vendors would provide a package(s) of code to
the platform vendor. If a chip vendor had a large number of config knobs for
validation or just end customer configuration we wanted the person building the
platform to be able to set the config knobs to what made sense to that
platform. We also wanted to minimize the changes that the platform vendor would
have to make to the chip vendors code, so syncing up with future code drops
would be easier.
I'm sorry that the terminology for PCD can get confusing and I think its partly
my fault. Here is my 10,000 foot view cheat sheet for how to use/conceptualize
PCD:
1) .DEC file - is the definition of the PCD entry. You get the pick the legal
forms, and default values for a PCD. When in doubt make it as flexible as
possible [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx].
2) .INF file - The PCD settings in the INF represent how the module was coded.
When in doubt use the generic form [Pcd] with PcdGet32() , and [FeaturePcd]
with FeaturePcdGet().
3) .DSC file - Within the constraints of how the PCD was defined and used in
modules you get to pick the form of the PCD for this specific build and set
values.
4) Ex - The Ex versions of the APIs include the GUID. These are only needed for
binaries or modules not built together. Each build will generate a unique token
space that the code uses, and this is to save space.
There are some other advantages to PCDs over h files. Since in any given build
a library is only built one time you can use FixedAtBuild PCD values to have
different settings on a per module basis for the library. So for example you
can pick a single driver to have very verbose DEBUG macro output while the
reset of the system is less verbose.
Thanks,
Andrew Fish
PS. Our dislike of lots of #ifdefs is why we ended up with FeaturePcdGet().
This lets you have an #ifdefs like construct where both sides always compile so
code never rots out. As long as you compiler does a good job dead stripping you
don't pay a size penalty in the binary.
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-devel
