Andrew, Thanks. I think I get it, another way to say it would be the PCD
replaces the #ifdef and #defines, replacing #if with compile time
conditional builds (though compiler optimizations) that prevent code rot
and #defines (and perhaps static const int var= which in c++ or other
compilers may be treated as #defines) with memory space that is patchable
in binaries? And the 1-4 view is how you define those variables to use.
Also, notice most things reference C - I presume one could get C++ code
(without exception handling) to work okay (change new/delete to
malloc/free) similar to how I set it up so I can code the Windows DDK using
C++?
Thanks again.
On Thu, Jan 31, 2013 at 1:21 PM, Andrew Fish <[email protected]> wrote:
>
> 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
>
>
------------------------------------------------------------------------------
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
