Mike --

We have traditionally used a preprocessor to convert the following into byte 
arrays:

UINT8(xx), UINT16(xx), UINT32(xx), UINT64(xx), BOOLEAN(TRUE|FALSE), 
GUID(struct-style {} or registry style "xxxxxx-yyy..."), "" (ASCII string 
no-nullterminator), L"" (UCS16 string no null-terminator), '' (ASCII 
character), L'' (UCS16 character) and DevicePath()

Tim

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Kinney, 
Michael D
Sent: Tuesday, June 14, 2016 3:58 PM
To: Zhu, Yonghong <yonghong....@intel.com>; edk2-devel@lists.01.org; Kinney, 
Michael D <michael.d.kin...@intel.com>
Subject: Re: [edk2] [RFC] Add more flexible PCD value formats in DEC/DSC files

Zhu Yonghong,

This proposal also applies to the optional default values in source INF files 
and PCD value assignments in FDF files.  We should also extend the syntax for 
the --pcd command line option to the build command to support this extended 
syntax.  So the specs impacted by this proposal are DEC/INF/DSC/FDF/Build.

Can you please provide a pointer to the spec that says C format GUIDs are 
supported for setting the value of a VOID* PCD?  I see several places where it 
states that only {} byte arrays are allowed.

Thanks,

Mike

> -----Original Message-----
> From: Zhu, Yonghong
> Sent: Monday, June 13, 2016 11:27 PM
> To: Kinney, Michael D <michael.d.kin...@intel.com>; 
> edk2-devel@lists.01.org; Kinney, Michael D 
> <michael.d.kin...@intel.com>
> Cc: Zhu, Yonghong <yonghong....@intel.com>
> Subject: RE: [RFC] Add more flexible PCD value formats in DEC/DSC 
> files
> 
> Hi Mike,
> 
> Sorry for the delay response. I have some comment:
> 1. Is this proposal only for DEC and DSC file ? Do we need cover the 
> Pcd value in the INF file and FDF file ?
> 2. From build spec, it require build tools support C format GUIDs as 
> Void * PCD value, current this feature is not implemented. So whether 
> this new proposal need to support the  C format GUIDs as Void * PCD value ?
> 
> Best Regards,
> Zhu Yonghong
> 
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Kinney, Michael D
> Sent: Thursday, May 19, 2016 3:22 AM
> To: edk2-devel@lists.01.org; Kinney, Michael D 
> <michael.d.kin...@intel.com>
> Subject: [edk2] [RFC] Add more flexible PCD value formats in DEC/DSC 
> files
> 
> Hello,
> 
> Today, the DEC/DSC specifications limit the PCD value formats to the 
> following:
> 
>   BOOLEAN  TRUE or FALSE
>   UINT8    8-bit decimal or hexadecimal value
>   UINT16   16-bit decimal or hexadecimal value
>   UINT32   32-bit decimal or hexadecimal value
>   UINT64   64-bit decimal or hexadecimal value
>   VOID*    ASCII string(e.g. "Hello")
>   VOID*    Unicode string(e.g. L"Hello")
>   VOID*    Array of hexadecimal byte values(e.g. {0x01, 0x02})
> 
> I would like to propose more flexible value formats for PCDs.
> In DEC and DSC files.  This would include the following:
> 
> * Character values using single quotes(e.g. 'A').
> * Multi-Character values using single quotes(e.g. 'ABCD').
> * Able to use TRUE/FALSE for UINT8/16/32/64 values
> * Able to use TRUE/FALSE in VOID* byte array
> * Able to use decimal values in VOID* byte array
> * Able to use single quote character values in VOID* byte arrays
> * Able to use ASCII string, Unicode String, Multi-Character
>   strings for UINT8/16/32/64 values as long as they fit in the
>   target type.
> 
> Some examples of this additional flexibility are:
> 
>   UINT8   TRUE
>   UINT8   FALSE
>   UINT8   0x12
>   UINT8   12
>   UINT8   'A'
>   UINT16   TRUE
>   UINT16  0x1234
>   UINT16  1234
>   UINT16  'AB'
>   UINT16  "A"
>   UINT32  0x12345678
>   UINT32  12345678
>   UINT32  "ABC"
>   UINT32  L"A"
>   UINT32  'ABCD'
>   UINT64  0x1234567812345678
>   UINT64  1234567812345678
>   UINT64  "ABCDEFG"
>   UINT64  L"ABC"
>   UINT64  'ABCDEFGH'
>   VOID*   {0x1, 0x2, 0x3}
>   VOID*   {10, 11, 12, 13, 14}
>   VOID*   {'X', 'Y', 'Z'}
>   VOID*   {TRUE, FALSE, FALSE, TRUE}
>   VOID*   {0x41, 0x42, 67, 68, 'E', 'F', TRUE, FALSE}
> 
> Here is a python function that can parse these formats and return an 
> python integer value that does not have any size limits.  Based on the 
> data type, the size can be checked to see the value return fits in the 
> target type.  All strings and byte arrays are reversed for little-endian byte 
> ordering.
> 
>   NOTE: Need to add explicit null-terminator for ASCII/Unicode
>   strings.  Multi-character constants are not null-terminated.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Kinney <michael.d.kin...@intel.com>
> 
> def ParseValue (Value):
>   if type(Value) == type(0):
>     return Value
>   if type(Value) <> type(''):
>     raise ValueError
>   Value = Value.strip()
>   if Value.startswith('L"') and Value.endswith('"'):
>     # Unicode String
>     List = list(Value[2:-1])
>     List.reverse()
>     Value = 0
>     for Char in List:
>       Value = (Value << 16) | ord(Char)
>     return Value
>   if Value[0] == '"' and Value[-1] == '"':
>     # ASCII String
>     List = list(Value[1:-1])
>     List.reverse()
>     Value = 0
>     for Char in List:
>       Value = (Value << 8) | ord(Char)
>     return Value
>   if Value[0] == "'" and Value[-1] == "'":
>     # Character constant
>     List = list(Value[1:-1])
>     List.reverse()
>     Value = 0
>     for Char in List:
>       Value = (Value << 8) | ord(Char)
>     return Value
>   if Value[0] == '{' and Value[-1] == '}':
>     # Byte array
>     Value = Value[1:-1]
>     List = [Item.strip() for Item in Value.split(',')]
>     List.reverse()
>     Value = 0
>     for Item in List:
>       ItemValue = ParseValue(Item)
>       if ItemValue > 255:
>         raise ValueError
>       Value = (Value << 8) | ItemValue
>     return Value
>   if Value.lower().startswith('0x'):
>     return int(Value, 16)
>   if Value[0].isdigit():
>     return int(Value, 10)
>   if Value.lower() == 'true':
>     return 1
>   if Value.lower() == 'false':
>     return 0
>   raise ValueError
> 
> Best regards,
> 
> Mike
> 
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Reply via email to