xref: /openbmc/pldm/docs/pdr_implementation.md (revision 571d7d44635580ee7bb29e84ee3114c472d3fc61)
1*571d7d44SManojkiran Eda# PDR Implementation
2*571d7d44SManojkiran Eda
3*571d7d44SManojkiran EdaWhile PLDM Platform Descriptor Records (PDRs) are mostly static information,
4*571d7d44SManojkiran Edathey can vary across platforms and systems. For this reason, platform specific
5*571d7d44SManojkiran EdaPDR information is encoded in platform specific JSON files. JSON files must be
6*571d7d44SManojkiran Edanamed based on the PDR type number. For example a state effecter PDR JSON file
7*571d7d44SManojkiran Edawill be named 11.json. The JSON files may also include information to enable
8*571d7d44SManojkiran Edaadditional processing (apart from PDR creation) for specific PDR types, for eg
9*571d7d44SManojkiran Edamapping an effecter id to a D-Bus object.
10*571d7d44SManojkiran Eda
11*571d7d44SManojkiran EdaThe PLDM responder implementation finds and parses PDR JSON files to create the
12*571d7d44SManojkiran EdaPDR repository. Platform specific PDR modifications would likely just result in
13*571d7d44SManojkiran EdaJSON updates. New PDR type support would require JSON updates as well as PDR
14*571d7d44SManojkiran Edageneration code. The PDR generator is a map of PDR Type -> C++ lambda to create
15*571d7d44SManojkiran EdaPDR entries for that type based on the JSON, and to update the central PDR repo.
16