On 31/03/16 14:37, Michael Brown wrote:
In a nutshell, I think iPXE should:
- reflect the GUID / NAME / PATH triplet from the input to the output
verbatim,
- for each config knob <LabelN> requested, respond with
<LabelN>=<ValueN>.
(See also: "if a ConfigHdr is passed in with no request elements, all
of the settings being abstracted for that particular ConfigHdr
reference will be returned in the Results Field" -- but I think the
iPXE code already handles that.)
It turns out that iPXE already does exactly what you describe as the
correct behaviour here. :) We do reflect {GUID,NAME,PATH} verbatim.
The ASSERT() happens only when EDK2 passes in a NULL Request. iPXE
currently returns the full list of settings being abstracted (as per the
spec) but without any ConfigHdr, since we have no GUID, NAME or PATH to
reflect back.
I note that OvmfPkg/PlatformDxe/Platform.c's ExtractConfig() handles a
NULL Request by returning EFI_INVALID_PARAMETER. This originates from
HiiBlockToConfig(), which does:
if (Block == NULL || ConfigRequest == NULL) {
*Progress = ConfigRequest;
return EFI_INVALID_PARAMETER;
}
This code in OvmfPkg/PlatformDxe/Platform.c seems to violate the spec,
but seems to cause the rest of EDK2 to behave sensibly. If I patch iPXE
to violate the spec in the same way, by adding:
if ( ! ( request && request[0] ) ) {
DBGC ( snpdev, "SNPDEV %p ExtractConfig ignoring malformed "
"request\n", snpdev );
return EFI_INVALID_PARAMETER;
}
then I no longer get an ASSERT() from EDK2.
Should I apply the above patch to iPXE, to cause it to match the
spec-violating (but non-crashing) behaviour of
OvmfPkg/PlatformDxe/Platform.c?
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?
Michael
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
