> On Apr 14, 2016, at 4:23 AM, Michael Brown <mc...@ipxe.org> wrote: > > On 13/04/16 15:55, Andrew Fish wrote: >>> 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? >> >> I think it has to do with the limitation of one protocol per handle. If >> there are multiple instances how do they get the right one? > > That would make some sense. Other than DriverSampleDxe, has there ever been > a use case in which a driver actually uses multiple storage mechanisms > attached to the same handle? >
Yes. There are extreme end case kind of things that live out in the wild. >>> 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 think the concept is the form creator (UI creator) should be able to >> specify how values get stored. The obvious choices are EFI Variable, or >> local storage on the card. The API tries not to impose constrains, or make >> assumptions. > > The above simplified API does not impose any such constraints. It would > provide a simple name/value-pair API, with the driver completely free to > choose how values were actually stored. > It is hard to argue that using Hii to do simple things is kind of complex and hard to Grok. Seems like what we need is a library that hides the complexity for the simple case? If the library proves easy to use and popular we can propose to standardize some of the new APIs. The library could then be updated to deal with backwards compatibility. Thanks, Andrew Fish >> As I remember (it was a long time ago) it was a specification driven design. > > Always a sign of impending doom. :) > > Michael _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
