Michael: In UI, the question is shown to user, such as checkbox, oneof, orderlist, password. One HII driver exposes multiple questions. Those questions may refer to one buffer storage. For this usage, the C structure can be used as the buffer storage. Each question refers to one field in C structure. HiiConfigAccess ExtractConfig can retrieve the settings of all questions by ConfigResp string (&Offset=&Width=&Value=). And, those questions may refer to Name/Value storage. HiiConfigAccess ExtractConfig can retrieve the settings of all questions by ConfigResp string (&Name=&Value=). These two styles are supported.
Thanks Liming From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael Brown Sent: Thursday, April 14, 2016 7:47 PM To: Gao, Liming; Dong, Eric; Laszlo Ersek; Bi, Dandan Cc: Justen, Jordan L; edk2-devel-01; Ard Biesheuvel Subject: Re: [edk2] HII incompatibility between edk2 and iPXE? On 13/04/16 17:04, Gao, Liming wrote: > 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. No, it doesn't. Case 1: the driver uses a single storage. The best API is a simple name/value-pair mechanism. Case 2: the driver uses multiple storages (for some unspecified reason). The complexity of doing this can be handled by the driver that decides to introduce this complexity. The driver is responsible for deciding internally which storage is used for each variable name. The best API is still a simple name/value-pair mechanism. Case 3: the driver uses multiple storages (for some unspecified reason), and a design committee makes the choice that this internal driver implementation detail should (for some incomprehensible reason) be exposed outside of the driver. Extend the concept of "name" to incorporate "storage+name", and you are still left with a situation in which the best API is a simple name/value-pair mechanism. Consider a hypothetical alternative memcpy() modelled on the design approach taken by the EFI HII API. Using such a call might look something like this: char action_string[ 128 /* should be large enough */ ]; snprintf ( action_string, sizeof ( action_string ), "SourceAddress=%p&DestinationAddress=%p&CopyLength=%zd", src, dest, len ); efi_hii_memcpy ( action_string ); The implementation of such a function is left as a nightmare for the interested reader. 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
