Leif -- The reason that Liming mentions this is that we've had some bad experiences with namespace collision for the #defines associated with GUIDs. For example, Intel's Framework specifications used this, so when the PI specification tried to use a name for similar functionality, it could not (which is why you see "2" appended to protocol names when there was never a "1"). Some other groups (including, for example, TCG) have decided that they would like to use EFI_ as a namespace for their specific context. And Intel has made some slips in this area within the UEFI universe, esp. in the EDK2 implementation.
Consider the case where the UEFI specification might want to implement some UEFI device tree protocol or GUID. The name EFI_DEVICE_TREE_GUID defined implies that it is an EFI device tree, when, in fact, it is merely produced by an EFI component. I would suggest (at least) further qualifying the name to make it clear which agent in the ecosystem "owns" the definition of the device tree. Tim -----Original Message----- From: Leif Lindholm [mailto:leif.lindh...@linaro.org] Sent: Monday, December 09, 2013 9:41 AM To: Gao, Liming Cc: edk2-devel@lists.sourceforge.net Subject: Re: [edk2] GUID for Flattened Device Tree in configuration table. Thank you. The code below is taken from the GRUB or Linux efi.h header, and as such prepends "EFI_" for namespace reasons. / Leif On Mon, Dec 09, 2013 at 02:18:20PM +0000, Gao, Liming wrote: > Yes. GUID format is correct. For GUID macro, it doesn't belong to UEFI spec. > So, I suggest to remove prefix EFI_. > > -----Original Message----- > From: Grant Likely [mailto:grant.lik...@secretlab.ca] > Sent: Monday, December 9, 2013 8:45 PM > To: Leif Lindholm; edk2-devel@lists.sourceforge.net; Roy Franz > Subject: [edk2] GUID for Flattened Device Tree in configuration table. > > Hi all, > > We (Linaro) are working on support for passing a flattened device tree > (FDT) via the UEFI configuration table. Before we publish patches, I want to > make sure that we've generated a valid UUID for the FDT entry. > We used the Linux tool uuidgen and it produced this: > > #define EFI_DEVICE_TREE_GUID \ > { \ > 0xb1b621d5, 0xf19c, 0x41a5, {0x83, 0x0b, 0xd9, 0x15, 0x2c, 0x69, 0xaa, > 0xe0 } \ > } > > I'm asking here to make sure we haven't made a fundamental error that gets > implemented by some firmware. Have we done the right thing? > > g. > > ------------------------------------------------------------------------------ > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
