On Thu, Oct 18, 2018 at 02:43:37PM +0530, Sumit Garg wrote: > On Thu, 18 Oct 2018 at 14:04, Leif Lindholm <leif.lindh...@linaro.org> wrote: > > > > On Thu, Oct 18, 2018 at 12:59:32PM +0530, Sumit Garg wrote: > > > > So, looking at the OpTee sources, TEE_UUID is defined as a struct, to > > > > exactly the same layout as the EFI_GUID type (which is a typedef of > > > > the GUID struct). Could we add a OPTEE_UUID typedef for the same > > > > struct in OpteeLib.h? > > > > > > > > Since it comes in as an OPTEE_MESSAGE_PARAM_VALUE, alignment is > > > > already guaranteed to be 64-bit. > > > > > > > > (This also deserves a comment explaining how EFI_GUID basically > > > > follows rfc4122, but uses little-endian for the timestamp fields.) > > > > > > Actually, OP-TEE also uses little-endian format for timestamp fields. > > > You can refer to [1] for conversion from network byte order (octets) > > > to little-endian and vice-versa. > > > > > > So for communications among secure world and non-secure world it uses > > > network byte order for UUID/GUID to comply with rfc4122. > > > > > > [1] https://github.com/OP-TEE/optee_os/blob/master/core/tee/uuid.c > > > > Huh, ok. That's good to know. > > It does however not change my comments. Since we're dealing with data > > structures of a known layout, I am not a fan of treating them as byte > > arrays. > > > > But calling UUID struct with swapped timestamp as OPTEE_UUID would > also be misnomer. I am not sure regarding appropriate naming for that > struct.
That's a fair point. We could call it RFC4122_UUID for now. There could even be a case to add that to BaseLib at some point (but probably not while there is only one user). Regards, Leif > On the other hand, we have byte array of 16 octets as per network byte > order complying with rfc4122 which also doesn't imply swapped > timestamp. > > -Sumit > > > / > > Leif _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
