> On Oct 15, 2015, at 6:02 AM, Nilesh <[email protected]> wrote: > > Hi, > > > > The UEFI specification (version 2.5) describes > EFI_SMART_CARD_EDGE_PROTOCOL's 'GetData' function as follows - > > "The function is generic for any kind of data, but driver and application > must share an EFI_GUID that identify the data." One of the input parameters > of this function is 'DataId', which is of type 'EFI_GUID', and is used to > define type of data to be retrieved. > > > > The question is - how to share the EFI_GUID based information between the > driver and the application? The other functions of this protocol does not > provide any way to share such information. Is there any standard mapping / > information available for such EFI_GUIDs? > > [ Note: There are couple of functions in this protocol (i.e. 'SignData' and > 'DecryptData'), which also accepts EFI_GUID parameters. However, the > expected EFI_GUID values of these parameters have been defined in the UEFI > specification along with the function description. ] > > > > I believe, the GetData function can expect Object IDs of the objects present > on the SmartCard to retrieve related data. Hence, it might be helpful to > have a mapping between these OIDs and EFI_GUIDs. However,these Object IDs > could be different for different type of cards (i.e. PIV, openPGP etc), > which makes it difficult to pre-define them in Spec. But how this > information can be shared between driver and the app? Is it expected to have > EFI_GUIDs defined per SMART_CARD_EDGE _PROTOCOL implementation and shared > using common header file? > > > > I am a newbie in EDK and Smart Card development. All comments and > suggestions are very much appreciated. >
Nilesh, In general the use of EFI_GUID (UUID) as a name is like having an enumerated type in the specification, but it has the side benefit that the enumeration is not owned by the specification. So a vendor, OEM, BIOS Vendor, or even other specification can define a value, and since it is a GUID/UUID that value will never conflict with the UEFI specification, or any value used in any other implementation. So the EFI_GUIDin the API is designed for extensibility. Whom ever defines new GUIDs would define how it works. In general in the edk2 the package owner would add a GUID definition in the packages GUID directory that included the GUID value, global C name and the data structures associated with the GUID. The package .DEC file would also get its [Guids] section updated for the new GUID. So you add MyPackage/Include/Guid/NewGuid.h and update MyPackage/MyPackage.dec, assuming MyPackage is the name of the package you own, and NewGuid is the name of the GUID you defined. Thanks, Andrew Fish > > > Best Regards, > > Nilesh > > _______________________________________________ > 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
