> -----Original Message----- > From: Michael Brown [mailto:mc...@ipxe.org] > Sent: Saturday, April 02, 2016 12:50 AM > To: Laszlo Ersek; Dong, Eric; Bi, Dandan > Cc: Justen, Jordan L; edk2-devel-01; Ard Biesheuvel > Subject: Re: [edk2] HII incompatibility between edk2 and iPXE? > > 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?
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. > > Michael _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
