Michael: UEFI spec Chapter 31 Human Interface Infrastructure Overview and Chapter section 2 Design discussion and Chapter 33 HII Configuration Processing and Browser Protocol section 2 Configuration Strings gives the details on UEFI HII design and Configuration string format. One HII package list maps to one Hii Handle and Device Handle. Its HiiConfigAccess protocol is installed in its mapped device handle. This protocol is used to read/write its setting and provide question callback. HII package list includes form package that includes zero or more storages and more questions. So, HiiConfigAccess protocol needs to manage all questions together. UEFI HII designs ConfigRequest and ConfigResp strings to describe multiple questions. Buffer storage and Name storage are handled by ConfigAccess protocol. Buffer storage is one structure buffer that relates to more than one questions. Each question refers to one field in the structure. Each question value is specified with Offset and width. Name st orage is Name/Value pair to map one question. EFI var storage is a specific buffer storage. its data is saved in EFI variable with the same storage Name/Guid. It is not handled by HiiConfigAccess protocol.
Thanks Liming From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael Brown Sent: Wednesday, April 13, 2016 6:51 PM To: Dong, Eric <eric.d...@intel.com>; Laszlo Ersek <ler...@redhat.com>; Bi, Dandan <dandan...@intel.com> Cc: Justen, Jordan L <jordan.l.jus...@intel.com>; edk2-devel-01 <edk2-de...@ml01.01.org>; Ard Biesheuvel <ard.biesheu...@linaro.org> Subject: Re: [edk2] HII incompatibility between edk2 and iPXE? On 13/04/16 03:33, Dong, Eric wrote: >>>> 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: OK, but why? What is the concrete purpose of this, that could not be achieved by more simply having multiple EFI_HII_CONFIG_ACCESS_PROTOCOL instances? > 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. For the most common case of an EFI_HII_CONFIG_ACCESS_PROTOCOL instance which exposes a single storage, it seems to be meaningless. Does it have any meaning in this (most common) situation? > 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. I'm sorry to disagree, but they are much too convoluted to serve as reference examples. This is possibly a reflection of the excessive complexity in the HII database design. As far as I can tell, all the functionality of ExtractConfig() could be provided with a very simple API such as: EFI_STATUS EFIAPI ExtractConfig ( IN CONST EFI_HII_CONFIG_ACCESS_PROTOCOL *This, IN CONST EFI_STRING Name, OUT EFI_STRING *Value ) I am morbidly interested to know how the HII database API passed even a minimal design review. Michael _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org> https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
