On 03/31/16 06:43, Michael Brown wrote: > On 31/03/16 02:17, Dong, Eric wrote: >>> Those sections of the UEFI spec are so badly written that I cannot begin >>> to guess what might count as either correct or incorrect. >>> >>> Could you please give a concrete example of what you think iPXE should >>> be returning here? >>> >> We have a sample driver in MdeModulePkg/Universal/DriverSampleDxe. It >> also use a Name/Value varstore. You can reference that driver about >> how to implement the EFI Config Access Protocol. > > That doesn't answer my question. The answer I'm looking for is the > actual string that you expect iPXE to be returning. This should be a > one-line answer in the form of a string. > > Solid examples such as this are sorely lacking from both this part of > the UEFI specification and the EDK2 codebase. > > Could you please give a concrete example of what you think iPXE should > be returning here?
I can't give you a concrete example, but I think the format can be deduced from the BNF in 33.2.1 "String Syntax", and from the documentation of EFI_HII_CONFIG_ACCESS_PROTOCOL.ExtractConfig(). iPXE's ExtractConfig() protocol member function is called with a <ConfigRequest>-formatted input string, and it is expected to return a <ConfigAltResp>-formatted output string. Let's try to apply the grammar's rules for the input: <ConfigRequest> -> <ConfigHdr> <RequestElement>* -> <GuidHdr>’&’ <NameHdr>’&’ <PathHdr> <RequestElement>* -> ‘GUID=’<Guid>’&’ ‘NAME=’<String>’&’ ‘PATH=’<UEFI binary Device Path represented as hex number> <RequestElement>* -> ‘GUID=’<Guid>’&’ ‘NAME=’<String>’&’ ‘PATH=’<UEFI binary Device Path represented as hex number> <RequestElement>* -> ‘GUID=’<Guid>’&’ ‘NAME=’<String>’&’ ‘PATH=’<UEFI binary Device Path represented as hex number> (‘&’<BlockName> | ‘&’<Label>)* Since -- I think -- you don't generate a form (IFR) that implies varstore- / block-based representation, I *think* that in the input (= request) string that you get, the second branch of the alternative visible above will be used (i.e., "Label"). In short, you should be getting a string like GUID=<Guid>&NAME=<String>&PATH=<UEFI binary Device Path represented as hex number>&<Label1>&<Label2>&<Label3>...&<LabelN> where the <Label>s should correspond to the configuration knobs that the iPXE driver exports (i.e., they come from the IFR -- see your efi_snp_hii_questions() function). ... You seem to have a DBGC for the request string in place already (in efi_snp_hii_extract_config()), so the above should be easy to confirm. In response, I think the following grammar substitutions should apply: <ConfigAltResp> -> <ConfigResp> [‘&’ <AltResp>]* -> <ConfigResp> -> <ConfigHdr> <ConfigBody> -> ‘GUID=’<Guid>’&’ ‘NAME=’<String>’&’ ‘PATH=’<UEFI binary Device Path represented as hex number> <ConfigElement>* -> ‘GUID=’<Guid>’&’ ‘NAME=’<String>’&’ ‘PATH=’<UEFI binary Device Path represented as hex number> (‘&’<BlockConfig> | ‘&’<NvConfig>)* Similarly to the request, the second branch of the alternative should be employed, I think. So, substituting the <NvConfig> rule: -> ‘GUID=’<Guid>’&’ ‘NAME=’<String>’&’ ‘PATH=’<UEFI binary Device Path represented as hex number> (‘&’ (<Label>’=’<String> | <Label>’=’<Number>))* Which translates to the following response string: GUID=<Guid>&NAME=<String>&PATH=<UEFI binary Device Path represented as hex number>&<Label1>=<Value1>&<Label2>=<Value2>&...&<LabelN>=<ValueN> 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.) ... I suspect iPXE's ExtractConfig() logic is almost complete, except it doesn't reflect GUID / NAME / PATH (= the "routing information") in the output. Shouldn't be hard to try out. Thanks, Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
