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?
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.
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
