Hi Andrew, Thank so much for your detailed reply.
Best Regards, Nilesh -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Thursday, October 15, 2015 8:42 PM To: Nilesh <[email protected]> Cc: [email protected] Subject: Re: [edk2] [EDK II] implementing EFI_SMART_CARD_EDGE_PROTOCOL.GetData > 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
