> -----Original Message----- > From: edk2-devel [mailto:[email protected]] On Behalf Of Laszlo > Ersek > Sent: Thursday, May 19, 2016 2:26 AM > To: Kinney, Michael D <[email protected]> > Cc: [email protected] <[email protected]> > Subject: Re: [edk2] [RFC] Structured PCD Proposal > > On 05/19/16 01:28, Kinney, Michael D wrote: > > [snip] > > > ## C Structure Syntax Proposal > > * Use C typedef syntax to describe complex C structures > > * Use a C language parser with support for struct/union/array/bit > > fields/pack > > * Recommend use of libclang C language parser into Abstract Syntax Tree > > (AST) > > - Included with LLVM release > > - http://llvm.org/releases/download.html > > - http://clang.llvm.org/doxygen/group__CINDEX.html > > * Recommend use of Python bindings for CLANG for EDK II Python based > > BaseTools > > - pip install clang > > What versions are necessary? On RHEL-7, the following versions are > available (from EPEL only; RHEL does not provide clang): > > clang-devel: 3.4.2-8.el7 > python-pip: 7.1.0-1.el7
I have not tried the prototype on RHEL-7 yet. For Fedora 23, we have used: $ sudo dnf install clang $ git clone -b release_37 https://github.com/trolldbois/python-clang $ cd python-clang $ sudo python setup.py install > > > > > ## DEC File Extensions > > * Declare link between PCD and C data structure and token range for fields > > * @Include path to include file with C typedef [Required] > > * Replace |VOID*| with name of C typedef > > * @TokenMap path to file with token number assignments [Optional] > > * Range of token numbers to assign to fields in C typedef [Required] > > * Example: > > > > ``` > > # @Include Include/Pcd/AcpiLowerPowerIdleTable.h > > # @TokenMap Include/Pcd/AcpiLowerPowerIdleTable.map > > > gPlatformTokenSpaceGuid.AcpiLowPowerIdleTable > |{}|ACPI_LOW_POWER_IDLE_TABLE|0x00010080 > |0x0E000200-0x0E0002FF > > ``` > > What does 0x00010080 mean here? That is the token number for the PCD gPlatformTokenSpaceGuid.AcpiLowPowerIdleTable. That is the same syntax that is used for all PCDs today. In the DEC file all PCDs are assigned a token number. For a Structured PCD, we have added the 5th Parameter on this PCD declaration line that is the range of token number that Are assigned to fields within the Structured PCD. We want to keep the token number for the PCD declaration in the DEC file for backwards compatibility. For example, the following PCD declared in MdeModulePkg/MdeModulePkg.dec: ## PCI Serial Device Info. It is an array of Device, Function, and Power Management # information that describes the path that contains zero or more PCI to PCI briges # followed by a PCI serial device. Each array entry is 4-bytes in length. The # first byte is the PCI Device Number, then second byte is the PCI Function Number, # and the last two bytes are the offset to the PCI power management capabilities # register used to manage the D0-D3 states. If a PCI power management capabilities # register is not present, then the last two bytes in the offset is set to 0. The # array is terminated by an array entry with a PCI Device Number of 0xFF. For a # non-PCI fixed address serial device, such as an ISA serial device, the value is 0xFF. # @Prompt Pci Serial Device Info gEfiMdeModulePkgTokenSpaceGuid.PcdSerialPciDeviceInfo|{0xFF}|VOID*|0x00010067 If we convert this VOID* PCD to a Structured PCD, the declaration could be updated to: ## PCI Serial Device Info. It is an array of Device, Function, and Power Management # information that describes the path that contains zero or more PCI to PCI briges # followed by a PCI serial device. Each array entry is 4-bytes in length. The # first byte is the PCI Device Number, then second byte is the PCI Function Number, # and the last two bytes are the offset to the PCI power management capabilities # register used to manage the D0-D3 states. If a PCI power management capabilities # register is not present, then the last two bytes in the offset is set to 0. The # array is terminated by an array entry with a PCI Device Number of 0xFF. For a # non-PCI fixed address serial device, such as an ISA serial device, the value is 0xFF. # @Prompt Pci Serial Device Info # @Include MdeModulePkg/Include/Pcd/SerialPciDeviceInfo.h gEfiMdeModulePkgTokenSpaceGuid.PcdSerialPciDeviceInfo|{}|VOID*|0x00010067|0xF0000000-0xF0000010 MdeModulePkg/Include/Pcd/SerialPciDeviceInfo.h ============================================== typedef struct { struct { // @Prompt PCI Device Number // @DefaultValue 0xFF UINT8 DeviceNumber; // @Prompt PCI Function Number UINT8 FunctionNumber; // @Prompt PCI Power Management Capabilities Register Offset UINT16 PciPowerManagementCapabilitiesOffset; } PciDeviceInfo[0]; } PCD_SERIAL_PCI_DEVICE_INFO; Notice that the token number of 0x00010067 is not changed. > > > > > * Recommended File Paths > > - <PackageName>/Include/Pcd/<StructuredPcdName>.h > > - <PackageName>/Include/Pcd/<StructuredPcdName>.map [Optional] > > - <PackageName>/Include/Pcd/<StructuredPcdName>.uni [Optional] > > * C Pre-Processor Support > > - Use of #include, #define, #if supported > > - #include limited to files in same package > > - Including files from other packages being evaluated > > > > ## C Structure Syntax > > * Support struct/union/array with nesting > > * Support bit fields > > Bit fields will require new PcdLib interaces, right? Yes. The new PcdLib functions to access Structured PCD fields are in the RFC. All bit fields have a base type of UINT8/16/32, so the 8/16/32 field access functions are used to access bitfields in the structure. > > [snip] > > Thanks > Laszlo > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
