> On 05/04/16 03:10, Dong, Eric wrote:
> >> On a separate but related note: The ConfigHdr portion of Request and
> >> Response seems to contain absolutely zero information by the time it
> >> reaches EFI_HII_CONFIG_ACCESS_PROTOCOL. As far as I can tell, it is
> >> meaningful only to EFI_HII_CONFIG_ROUTING_PROTOCOL and a sensible API
> >> design would never have exposed it to EFI_HII_CONFIG_ACCESS_PROTOCOL
> >> instances.
> >>
> >> Does the ConfigHdr have any meaning for EFI_HII_CONFIG_ACCESS_PROTOCOL,
> >> or is it just a pointless blob of noise?
> >
> > The GUID/NAME value in the ConfigHdr is get from the storage used in this
> > driver. If one driver has more than one storage, the Guid +
> Name specify which storage info will be return.
>
> Surely the EFI_HII_CONFIG_ACCESS_PROTOCOL's *This pointer already
> uniquely identifies the storage.
>
> (If not, then why not?)
The Config Access Protocol supports more than one storages in this protocol at
one time. Just like examples in DriverSampleDxe, it has three storages in this
driver:
//
// Define a Buffer Storage (EFI_IFR_VARSTORE)
//
varstore DRIVER_SAMPLE_CONFIGURATION, // This is the data structure type
varid = CONFIGURATION_VARSTORE_ID, // Optional VarStore ID
name = MyIfrNVData, // Define referenced name in vfr
guid = DRIVER_SAMPLE_FORMSET_GUID; // GUID of this buffer storage
//
// Define a EFI variable Storage (EFI_IFR_VARSTORE_EFI)
//
efivarstore MY_EFI_VARSTORE_DATA,
attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_NON_VOLATILE,
// EFI variable attribures
name = MyEfiVar,
guid = DRIVER_SAMPLE_FORMSET_GUID;
//
// Define a Name/Value Storage (EFI_IFR_VARSTORE_NAME_VALUE)
//
namevaluevarstore MyNameValueVar, // Define storage
reference name in vfr
name = STRING_TOKEN(STR_NAME_VALUE_VAR_NAME0), // Define Name list of this
storage, refer it by MyNameValueVar[0]
name = STRING_TOKEN(STR_NAME_VALUE_VAR_NAME1), // Define Name list of this
storage, refer it by MyNameValueVar[1]
name = STRING_TOKEN(STR_NAME_VALUE_VAR_NAME2), // Define Name list of this
storage, refer it by MyNameValueVar[2]
guid = DRIVER_SAMPLE_FORMSET_GUID; // GUID of this Name/Value
storage
The ConfigHdr string includes the Name + Guid + DevicePath info. The name +
guid is got from the storage definition. So in EFI_HII_CONFIG_ACCESS_PROTOCOL's
ExtractCofig function, it base on the input Name + guid info to know which
storage data need to be return. It's not meaningless.
Because we almost add all examples related to HII to DriverSampleDxe, this
driver may seems a little big. But I think these codes are valuable for the
newbie of Hii if he can spend some time to learn it.
>
> Thanks,
>
> Michael
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
