Re: [edk2] HII incompatibility between edk2 and iPXE?

[Michael Brown]

On 15/04/16 12:00, Gao, Liming wrote:

   In UI, the question is shown to user, such as checkbox, oneof,
orderlist, password. One HII driver exposes multiple questions. Those
questions may refer to one buffer storage. For this usage, the C
structure can be used as the buffer storage. Each question refers to one
field in C structure. HiiConfigAccess ExtractConfig can retrieve the
settings of all questions by ConfigResp string (===).
And, those questions may refer to Name/Value storage. HiiConfigAccess
ExtractConfig can retrieve the settings of all questions by ConfigResp
string (==). These two styles are supported.


Consider a hypothetical alternative memcpy() modelled on the design 
approach taken by the EFI HII API. Using such a call might look 
something like this:


  char action_string[ 128 /* should be large enough */ ];

  snprintf ( action_string, sizeof ( action_string ),
 "SourceAddress=%p=%p=%zd",
 src, dest, len );
  efi_hii_memcpy ( action_string );


Does that look to you like a sensible API for memcpy()?

If yes, then there's no point in any further discussion.

If no, then consider that "===" represents the same 
API design flaw.


Michael
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Michael Brown]

On 14/04/16 15:24, Andrew Fish wrote:

It is hard to argue that using Hii to do simple things is kind of complex and 
hard to Grok.


Not really.  Three people on this list (myself, Laszlo, and Eric) all 
managed to independently make the exact same mistake.  Either we're all 
incompetent, or there's a something wrong with the spec and the 
reference code.



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.


That would probably be helpful for code within EDK2.  It doesn't help 
external code such as iPXE, which has to maintain backwards 
compatibility all the way to EFI 1.10.


Michael
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Gao, Liming]

Michael:
  In UI, the question is shown to user, such as checkbox, oneof, orderlist, 
password. One HII driver exposes multiple questions. Those questions may refer 
to one buffer storage. For this usage, the C structure can be used as the 
buffer storage. Each question refers to one field in C structure. 
HiiConfigAccess ExtractConfig can retrieve the settings of all questions by 
ConfigResp string (===).  And, those questions may refer to 
Name/Value storage. HiiConfigAccess ExtractConfig can retrieve the settings of 
all questions by ConfigResp string (==). These two styles are 
supported.

Thanks
Liming
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael 
Brown
Sent: Thursday, April 14, 2016 7:47 PM
To: Gao, Liming; Dong, Eric; Laszlo Ersek; Bi, Dandan
Cc: Justen, Jordan L; edk2-devel-01; Ard Biesheuvel
Subject: Re: [edk2] HII incompatibility between edk2 and iPXE?

On 13/04/16 17:04, Gao, Liming wrote:
> UEFI spec Chapter 31 Human Interface Infrastructure Overview and
> Chapter section 2 Design discussion and Chapter 33 HII Configuration
> Processing and Browser Protocol section 2 Configuration Strings gives
> the details on UEFI HII design and Configuration string format. One HII
> package list maps to one Hii Handle and Device Handle. Its
> HiiConfigAccess protocol is installed in its mapped device handle. This
> protocol is used to read/write its setting and provide question
> callback. HII package list includes form package that includes zero or
> more storages and more questions. So, HiiConfigAccess protocol needs to
> manage all questions together.

No, it doesn't.

Case 1: the driver uses a single storage. The best API is a simple
name/value-pair mechanism.

Case 2: the driver uses multiple storages (for some unspecified reason).
The complexity of doing this can be handled by the driver that decides
to introduce this complexity. The driver is responsible for deciding
internally which storage is used for each variable name. The best API
is still a simple name/value-pair mechanism.

Case 3: the driver uses multiple storages (for some unspecified reason),
and a design committee makes the choice that this internal driver
implementation detail should (for some incomprehensible reason) be
exposed outside of the driver. Extend the concept of "name" to
incorporate "storage+name", and you are still left with a situation in
which the best API is a simple name/value-pair mechanism.


Consider a hypothetical alternative memcpy() modelled on the design
approach taken by the EFI HII API. Using such a call might look
something like this:

char action_string[ 128 /* should be large enough */ ];

snprintf ( action_string, sizeof ( action_string ),
"SourceAddress=%p=%p=%zd",
src, dest, len );
efi_hii_memcpy ( action_string );

The implementation of such a function is left as a nightmare for the
interested reader.

Michael
___
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Andrew Fish]

> On Apr 14, 2016, at 4:23 AM, Michael Brown  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

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Michael Brown]

On 13/04/16 17:04, Gao, Liming wrote:

   UEFI spec Chapter 31 Human Interface Infrastructure Overview and
Chapter section 2 Design discussion and Chapter 33 HII Configuration
Processing and Browser Protocol section 2 Configuration Strings gives
the details on UEFI HII design and Configuration string format. One HII
package list maps to one Hii Handle and Device Handle. Its
HiiConfigAccess protocol is installed in its mapped device handle. This
protocol is used to read/write its setting and provide question
callback. HII package list includes form package that includes zero or
more storages and more questions. So, HiiConfigAccess protocol needs to
manage all questions together.


No, it doesn't.

Case 1: the driver uses a single storage.  The best API is a simple 
name/value-pair mechanism.


Case 2: the driver uses multiple storages (for some unspecified reason). 
 The complexity of doing this can be handled by the driver that decides 
to introduce this complexity.  The driver is responsible for deciding 
internally which storage is used for each variable name.  The best API 
is still a simple name/value-pair mechanism.


Case 3: the driver uses multiple storages (for some unspecified reason), 
and a design committee makes the choice that this internal driver 
implementation detail should (for some incomprehensible reason) be 
exposed outside of the driver.  Extend the concept of "name" to 
incorporate "storage+name", and you are still left with a situation in 
which the best API is a simple name/value-pair mechanism.



Consider a hypothetical alternative memcpy() modelled on the design 
approach taken by the EFI HII API.  Using such a call might look 
something like this:


  char action_string[ 128 /* should be large enough */ ];

  snprintf ( action_string, sizeof ( action_string ),
 "SourceAddress=%p=%p=%zd",
 src, dest, len );
  efi_hii_memcpy ( action_string );

The implementation of such a function is left as a nightmare for the 
interested reader.


Michael
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Michael Brown]

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

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Gao, Liming]

Michael:
  UEFI spec Chapter 31 Human Interface Infrastructure Overview and Chapter 
section 2 Design discussion and Chapter 33 HII Configuration Processing and 
Browser Protocol section 2 Configuration Strings gives the details on UEFI HII 
design and Configuration string format. One HII package list maps to one Hii 
Handle and Device Handle. Its HiiConfigAccess protocol is installed in its 
mapped device handle. This protocol is used to read/write its setting and 
provide question callback. HII package list includes form package that includes 
zero or more storages and more questions. So, HiiConfigAccess protocol needs to 
manage all questions together. UEFI HII designs ConfigRequest and ConfigResp 
strings to describe multiple questions. Buffer storage and Name storage are 
handled by ConfigAccess protocol. Buffer storage is one structure buffer that 
relates to more than one questions. Each question refers to one field in the 
structure. Each question value is specified with Offset and width. Name st
 orage is Name/Value pair to map one question. EFI var storage is a specific 
buffer storage. its data is saved in EFI variable with the same storage 
Name/Guid. It is not handled by HiiConfigAccess protocol.

Thanks
Liming
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael 
Brown
Sent: Wednesday, April 13, 2016 6:51 PM
To: Dong, Eric <eric.d...@intel.com>; Laszlo Ersek <ler...@redhat.com>; Bi, 
Dandan <dandan...@intel.com>
Cc: Justen, Jordan L <jordan.l.jus...@intel.com>; edk2-devel-01 
<edk2-de...@ml01.01.org>; Ard Biesheuvel <ard.biesheu...@linaro.org>
Subject: Re: [edk2] HII incompatibility between edk2 and iPXE?

On 13/04/16 03:33, Dong, Eric wrote:
>>>> 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.
>>
>> Surely the EFI_HII_CONFIG_ACCESS_PROTOCOL's *This pointer already
>> uniquely identifies the storage.
>>
>> (If not, then why not?)
>
> The Config Access Protocol supports more than one storages in this protocol 
> at one time. Just like examples in DriverSampleDxe, it has three storages in 
> this driver:

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?

> The ConfigHdr string includes the Name + Guid + DevicePath info. The name + 
> guid is got from the storage definition. So in 
> EFI_HII_CONFIG_ACCESS_PROTOCOL's ExtractCofig function, it base on the input 
> Name + guid info to know which storage data need to be return. It's not 
> meaningless.

For the most common case of an EFI_HII_CONFIG_ACCESS_PROTOCOL instance
which exposes a single storage, it seems to be meaningless. Does it
have any meaning in this (most common) situation?

> Because we almost add all examples related to HII to DriverSampleDxe, this 
> driver may seems a little big. But I think these codes are valuable for the 
> newbie of Hii if he can spend some time to learn it.

I'm sorry to disagree, but they are much too convoluted to serve as
reference examples.

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 am morbidly interested to know how the HII database API passed even a
minimal design review.

Michael
___
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Andrew Fish]

> On Apr 13, 2016, at 3:51 AM, Michael Brown  wrote:
> 
> On 13/04/16 03:33, Dong, Eric wrote:
> 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.
>>> 
>>> Surely the EFI_HII_CONFIG_ACCESS_PROTOCOL's *This pointer already
>>> uniquely identifies the storage.
>>> 
>>> (If not, then why not?)
>> 
>> The Config Access Protocol supports more than one storages in this protocol 
>> at one time.  Just like examples in DriverSampleDxe, it has three storages 
>> in this driver:
> 
> 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? 

>> The ConfigHdr string includes the Name + Guid + DevicePath info.  The name + 
>>  guid is got from the storage definition. So in 
>> EFI_HII_CONFIG_ACCESS_PROTOCOL's ExtractCofig function, it base on the input 
>> Name + guid info to know which storage data need to be return. It's not 
>> meaningless.
> 
> For the most common case of an EFI_HII_CONFIG_ACCESS_PROTOCOL instance which 
> exposes a single storage, it seems to be meaningless.  Does it have any 
> meaning in this (most common) situation?
> 
>> Because we almost add all examples related to HII to DriverSampleDxe, this 
>> driver may seems a little big. But I think these codes are valuable for the 
>> newbie of Hii if he can spend some time to learn it.
> 
> I'm sorry to disagree, but they are much too convoluted to serve as reference 
> examples.
> 

Thats good feedback thanks. 

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

> I am morbidly interested to know how the HII database API passed even a 
> minimal design review.
> 

As I remember (it was a long time ago) it was a specification driven design. 
There seemed to be end case feature requirements coming out of the woodwork, 
and those features had to get accommodated by the design. In the legacy BIOS 
world the option ROM could take over the system a present a UI that was just 
code. In the EFI world the Hii base UI is this abstraction. So folks that had 
written legacy options ROMs got concerned and asked for lots of features. 

Thanks,

Andrew Fish

> Michael
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Michael Brown]

On 13/04/16 03:33, Dong, Eric wrote:

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.

Surely the EFI_HII_CONFIG_ACCESS_PROTOCOL's *This pointer already
uniquely identifies the storage.

(If not, then why not?)


The Config Access Protocol supports more than one storages in this protocol at 
one time.  Just like examples in DriverSampleDxe, it has three storages in this 
driver:


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?



The ConfigHdr string includes the Name + Guid + DevicePath info.  The name +  
guid is got from the storage definition. So in EFI_HII_CONFIG_ACCESS_PROTOCOL's 
ExtractCofig function, it base on the input Name + guid info to know which 
storage data need to be return. It's not meaningless.


For the most common case of an EFI_HII_CONFIG_ACCESS_PROTOCOL instance 
which exposes a single storage, it seems to be meaningless.  Does it 
have any meaning in this (most common) situation?



Because we almost add all examples related to HII to DriverSampleDxe, this 
driver may seems a little big. But I think these codes are valuable for the 
newbie of Hii if he can spend some time to learn it.


I'm sorry to disagree, but they are much too convoluted to serve as 
reference examples.


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 am morbidly interested to know how the HII database API passed even a 
minimal design review.


Michael
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Laszlo Ersek]

On 04/13/16 04:33, Dong, Eric wrote:
>> On 05/04/16 03:10, Dong, Eric wrote:
 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.
>>
>> Surely the EFI_HII_CONFIG_ACCESS_PROTOCOL's *This pointer already
>> uniquely identifies the storage.
>>
>> (If not, then why not?)
> 
> The Config Access Protocol supports more than one storages in this protocol 
> at one time.  Just like examples in DriverSampleDxe, it has three storages in 
> this driver:
>   //
>   // Define a Buffer Storage (EFI_IFR_VARSTORE)
>   //
>   varstore DRIVER_SAMPLE_CONFIGURATION, // This is the data structure type
> varid = CONFIGURATION_VARSTORE_ID,  // Optional VarStore ID
> name  = MyIfrNVData,// Define referenced name in vfr
> guid  = DRIVER_SAMPLE_FORMSET_GUID; // GUID of this buffer storage
> 
>   //
>   // Define a EFI variable Storage (EFI_IFR_VARSTORE_EFI)
>   //
>   efivarstore MY_EFI_VARSTORE_DATA,
> attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_NON_VOLATILE,  
> // EFI variable attribures  
> name  = MyEfiVar,
> guid  = DRIVER_SAMPLE_FORMSET_GUID;
> 
>   //
>   // Define a Name/Value Storage (EFI_IFR_VARSTORE_NAME_VALUE)
>   //
>   namevaluevarstore MyNameValueVar,// Define storage 
> reference name in vfr
> name = STRING_TOKEN(STR_NAME_VALUE_VAR_NAME0), // Define Name list of 
> this storage, refer it by MyNameValueVar[0]
> name = STRING_TOKEN(STR_NAME_VALUE_VAR_NAME1), // Define Name list of 
> this storage, refer it by MyNameValueVar[1]
> name = STRING_TOKEN(STR_NAME_VALUE_VAR_NAME2), // Define Name list of 
> this storage, refer it by MyNameValueVar[2]
> guid = DRIVER_SAMPLE_FORMSET_GUID; // GUID of this Name/Value 
> storage
> 

What is the difference between these storage types? What are their
characteristics? Are they specified somewhere?

Thanks,
Laszlo


> The ConfigHdr string includes the Name + Guid + DevicePath info.  The name +  
> guid is got from the storage definition. So in 
> EFI_HII_CONFIG_ACCESS_PROTOCOL's ExtractCofig function, it base on the input 
> Name + guid info to know which storage data need to be return. It's not 
> meaningless. 
> 
> Because we almost add all examples related to HII to DriverSampleDxe, this 
> driver may seems a little big. But I think these codes are valuable for the 
> newbie of Hii if he can spend some time to learn it.
> 
>>
>> Thanks,
>>
>> Michael
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Dong, Eric]

> On 05/04/16 03:10, Dong, Eric wrote:
> >> 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.
> 
> Surely the EFI_HII_CONFIG_ACCESS_PROTOCOL's *This pointer already
> uniquely identifies the storage.
> 
> (If not, then why not?)

The Config Access Protocol supports more than one storages in this protocol at 
one time.  Just like examples in DriverSampleDxe, it has three storages in this 
driver:
  //
  // Define a Buffer Storage (EFI_IFR_VARSTORE)
  //
  varstore DRIVER_SAMPLE_CONFIGURATION, // This is the data structure type
varid = CONFIGURATION_VARSTORE_ID,  // Optional VarStore ID
name  = MyIfrNVData,// Define referenced name in vfr
guid  = DRIVER_SAMPLE_FORMSET_GUID; // GUID of this buffer storage

  //
  // Define a EFI variable Storage (EFI_IFR_VARSTORE_EFI)
  //
  efivarstore MY_EFI_VARSTORE_DATA,
attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_NON_VOLATILE,  
// EFI variable attribures  
name  = MyEfiVar,
guid  = DRIVER_SAMPLE_FORMSET_GUID;

  //
  // Define a Name/Value Storage (EFI_IFR_VARSTORE_NAME_VALUE)
  //
  namevaluevarstore MyNameValueVar,// Define storage 
reference name in vfr
name = STRING_TOKEN(STR_NAME_VALUE_VAR_NAME0), // Define Name list of this 
storage, refer it by MyNameValueVar[0]
name = STRING_TOKEN(STR_NAME_VALUE_VAR_NAME1), // Define Name list of this 
storage, refer it by MyNameValueVar[1]
name = STRING_TOKEN(STR_NAME_VALUE_VAR_NAME2), // Define Name list of this 
storage, refer it by MyNameValueVar[2]
guid = DRIVER_SAMPLE_FORMSET_GUID; // GUID of this Name/Value 
storage


The ConfigHdr string includes the Name + Guid + DevicePath info.  The name +  
guid is got from the storage definition. So in EFI_HII_CONFIG_ACCESS_PROTOCOL's 
ExtractCofig function, it base on the input Name + guid info to know which 
storage data need to be return. It's not meaningless. 

Because we almost add all examples related to HII to DriverSampleDxe, this 
driver may seems a little big. But I think these codes are valuable for the 
newbie of Hii if he can spend some time to learn it.

> 
> Thanks,
> 
> Michael
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Michael Brown]

On 05/04/16 03:10, Dong, Eric wrote:

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.


Surely the EFI_HII_CONFIG_ACCESS_PROTOCOL's *This pointer already 
uniquely identifies the storage.


(If not, then why not?)

Thanks,

Michael
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Michael Brown]

On 01/04/16 21:41, Laszlo Ersek wrote:

I am (and was) aware of "MdeModulePkg/Universal/DriverSampleDxe", the same 
driver that Eric recommended as an example in this thread earlier. In my opinion, that 
driver is supremely over-sized and -cluttered to be usable as a learning tool.


I'm glad it's not just me.  :)


I'm sorry that I couldn't help more. If we want to go with practicality (= "working 
code trumps precise documentation"), then you might want to consider applying the 
patch you proposed above. (Just don't add more angry comments pls.)


Thanks for all your detailed help in tracking this down.  I appreciate it.

I've pushed this workaround patch to iPXE:

  http://git.ipxe.org/ipxe.git/commitdiff/5238c85

along with a detailed (and non-angry) commit message.

Thanks again,

Michael
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Dong, Eric]

> -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  requested, respond with
> >> =.
> >>
> >> (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

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Laszlo Ersek]

On 04/01/16 18:49, Michael Brown wrote:
> 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  requested, respond with
>>> =.
>>>
>>> (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.

Does the spec require, perhaps, that in this case the callee construct GUID / 
NAME / PATH from scratch? In theory at least, the callee knows all that 
information. The HiiConstructConfigHdr() helper function seems to be suitable 
for this.

> 
> 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;
>   }

Indeed.

> This code in OvmfPkg/PlatformDxe/Platform.c seems to violate the spec,

That's possible. I guess when I was writing this code, I also may not have had 
a 100% understanding of the spec.

I went with the following guidance from 
"EFI_HII_CONFIG_ROUTING_PROTOCOL.BlockToConfig()": 'This helper function is to 
be called by drivers to map configuration data stored in byte array (“block”) 
formats such as UEFI Variables into current configuration strings.'

Also, from "EFI_HII_CONFIG_ACCESS_PROTOCOL.RouteConfig()": 'If the driver's 
configuration is stored in a linear block of data and the driver's name / value 
pairs are
in  format, it may use the ConfigToBlock helper function (above) 
to simplify the job.'

I did look at a number of HII examples in the edk2 tree. As far as I recall, I 
found them quite non-uniform, and couldn't connect them to the spec overly well.

>
> but seems to cause the rest of EDK2 to behave sensibly.

Well, in the caller at hand, function HiiConfigRoutingExportConfig() in 
"MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c", we have

Status = ConfigAccess->ExtractConfig (
 ConfigAccess,
 NULL,
 ,
 
 );
if (EFI_ERROR (Status)) {
  //
  // Update AccessResults by getting default setting from IFR when 
HiiPackage is registered to HiiHandle 
  //
  if (HiiHandle != NULL && DevicePath != NULL) {
IfrDataParsedFlag = TRUE;
Status = GetFullStringFromHiiFormPackages (Database, DevicePath, 
, , NULL);
//
// Get the full request string to get the Current setting again.
//
if (!EFI_ERROR (Status) && ConfigRequest != NULL) {
  Status = ConfigAccess->ExtractConfig (
   ConfigAccess,
   ConfigRequest,
   ,
   
   );

This is what makes the behavior that you identified work. The code looks quite 
"deliberate" (as opposed to "incidental"); it originates from commit 
6e3f5b2aa919 ("Fix K8 and Sct failure.").

BTW, Heyi Guo had found some problems in this OVMF code, with the SCT, and 
submitted some patches. I didn't accept them; as far as I remember -- and I 
could be wrong after all this time -- I could see no compelling argument / 
precise references to the spec, proving why the OVMF code was wrong, and why 
the suggested patches were right. See the patches & discussion here; I think 
they could be quite relevant:

http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15101/focus=15103
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15101/focus=15104

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

I don't know. I don't (and didn't) even claim that the OvmfPkg code is 100% 
correct, according to the spec -- I'm simply incapable of determining that. I 
didn't mean to imply that I was an "HII expert" either. All I can say is the 

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Michael Brown]

On 31/03/16 14:06, Dong, Eric wrote:

 1. Enhance the Results string for ExtractConfig function like below:

Request = “GUID===&…”
Results = “GUIDValue1=Value2=Value3…”
PS: Red string you can get from the input Request string. Blue string is
the true value for each knob in your driver.


Thank you for the input.  What you describe is exactly how iPXE already 
behaves.  See my previous e-mail for more details.



Also I think maybe you need to enhance the RouteConfig function. The
input Configuration string is like below. you need to get the value
filed for each knob and set it to your driver.


That's already what our RouteConfig() does.

Thanks,

Michael
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Michael Brown]

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  requested, respond with
=.

(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

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Laszlo Ersek]

On 03/31/16 15:37, Michael Brown wrote:
> On 31/03/16 11:13, Laszlo Ersek wrote:
>> Which translates to the following response string:
>>
>> GUID===> hex number>&=&=&...&=
>>
>> In a nutshell, I think iPXE should:
>> - reflect the GUID / NAME / PATH triplet from the input to the output
>> verbatim,
>> - for each config knob  requested, respond with
>> =.
>>
>> (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.
> 
> Thank you, Laszlo!  That is exactly the kind of answer I was looking for.
> 
> I'm about to get on a plane, but will update the iPXE code ASAP.  What's
> the easiest way to reproduce the original ASSERT() that you were seeing?
>  If I build EDK2 as of 8a45f80edad4, should I see the assertion as soon
> as I power on the VM, or do I need to do something to trigger it?

Right, building OVMF from edk2 at 8a45f80edad4, then launching QEMU such
that a NIC with an IPXE option ROM is present (from a CONFIG=qemu IPXE
build), then finally *booting* an UEFI application, should trigger the
problem. (For example, launching just the UEFI shell should suffice.)

The following commands should do it:

(
  CODE=.../OVMF_CODE.fd
  TMPL=.../OVMF_VARS.fd
  IPXE_EFI_DRV=.../1af41000.efidrv

  if ! [ -e vars.fd ]; then
cp $TMPL vars.fd
  fi

  qemu-system-x86_64 \
-m 2048 \
-M pc \
-enable-kvm \
-device qxl-vga \
\
-drive if=pflash,readonly,format=raw,file=$CODE \
-drive if=pflash,format=raw,file=vars.fd \
\
-debugcon file:debug.log \
-global isa-debugcon.iobase=0x402 \
\
-chardev stdio,signal=off,mux=on,id=char0 \
-mon chardev=char0,mode=readline,default \
-serial chardev:char0 \
\
-netdev user,id=netdev0 \
-device virtio-net-pci,netdev=netdev0,romfile=$IPXE_EFI_DRV
)

The assertion failure will be at the end of "debug.log".

The model of the emulated / virtual NIC is irrelevant; e.g., the rtl8139
device (with 10ec8139.efidrv) should reproduce the problem similarly.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Michael Brown]

On 31/03/16 11:13, Laszlo Ersek wrote:

Which translates to the following response string:

GUID===&=&=&...&=

In a nutshell, I think iPXE should:
- reflect the GUID / NAME / PATH triplet from the input to the output verbatim,
- for each config knob  requested, respond with =.

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


Thank you, Laszlo!  That is exactly the kind of answer I was looking for.

I'm about to get on a plane, but will update the iPXE code ASAP.  What's 
the easiest way to reproduce the original ASSERT() that you were seeing? 
 If I build EDK2 as of 8a45f80edad4, should I see the assertion as soon 
as I power on the VM, or do I need to do something to trigger it?


Thanks again!

Michael
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Dong, Eric]

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, March 31, 2016 6:14 PM
> To: Michael Brown; Dong, Eric; Bi, Dandan
> Cc: edk2-devel-01; Justen, Jordan L; Ard Biesheuvel
> Subject: Re: HII incompatibility between edk2 and iPXE?
>
> 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
> -formatted input string, and it is expected to return a
> -formatted output string.
>
> Let's try to apply the grammar's rules for the input:
>
>
> -> 
>*
> -> ’&’
>’&’
>
>*
> -> ‘GUID=’’&’
>‘NAME=’’&’
>‘PATH=’
>*
> -> ‘GUID=’’&’
>‘NAME=’’&’
>‘PATH=’
>*
> -> ‘GUID=’’&’
>‘NAME=’’&’
>‘PATH=’
>(‘&’ | ‘&’)*
>
> 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=== represented as hex number>&&&...&
>
> where the 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:
>
>
> -> 
>[‘&’ ]*
> -> 
> -> 
>
> -> ‘GUID=’’&’
>‘NAME=’’&’
>‘PATH=’
>*
> -> ‘GUID=’’&’
>‘NAME=’’&’
>‘PATH=’
>(‘&’ | ‘&’)*
>
> Similarly to the request, the second branch of the alternative should be
> employed, I think. So, substituting the  rule:
>
> -> ‘GUID=’’&’
>‘NAME=’’&’
>‘PATH=’
>(‘&’ (’=’ | ’=’))*
>
> Which translates to the following response string:
>
> GUID=== represented as hex
> number>&=&=&...&= >
>
> In a nutshell, I think iPXE should:
> - reflect the GUID / NAME / PATH triplet from the input to the output
> verbatim,
> - for each config knob  requested, respond with
> =.
>
> (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.

From former debug info, I think driver code should enhanced like below:
1.  Enhance the Results string for ExtractConfig function like below:
Request = “GUID===&…”
Results = “GUIDValue1=Value2=Value3…”
PS: Red string you can get from the input Request string. Blue string is the 
true value for each knob in your driver.
 EFI_STATUS
 (EFIAPI * EFI_HII_ACCESS_EXTRACT_CONFIG ) (
 IN CONST EFI_HII_CONFIG_ACCESS_PROTOCOL *This,
 IN CONST EFI_STRING  Request,
 OUT EFI_STRING *Progress,
 OUT EFI_STRING  *Results
 );

Also I think maybe you need to enhance the RouteConfig function. The input 
Configuration string is like below. you need to get the value filed for each 
knob and set it to your driver. This value is updated by end user and press 
save button to save it.
Configuration = “GUIDValue1=Value2=Value3…”

 EFI_STATUS
 (EFIAPI * EFI_HII_ACCESS_ROUTE_CONFIG ) (
 IN CONST EFI_HII_CONFIG_ACCESS_PROTOCOL *This,
 IN CONST EFI_STRING  Configuration,
 OUT EFI_STRING *Progress
 );

>
> Thanks,
> Laszlo

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Laszlo Ersek]

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 
-formatted input string, and it is expected to return a 
-formatted output string.

Let's try to apply the grammar's rules for the input:

   
-> 
   *
-> ’&’
   ’&’
   
   *
-> ‘GUID=’’&’
   ‘NAME=’’&’
   ‘PATH=’
   *
-> ‘GUID=’’&’
   ‘NAME=’’&’
   ‘PATH=’
   *
-> ‘GUID=’’&’
   ‘NAME=’’&’
   ‘PATH=’
   (‘&’ | ‘&’)*

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===&&&...&

where the 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:

   
-> 
   [‘&’ ]*
-> 
-> 
   
-> ‘GUID=’’&’
   ‘NAME=’’&’
   ‘PATH=’
   *
-> ‘GUID=’’&’
   ‘NAME=’’&’
   ‘PATH=’
   (‘&’ | ‘&’)*

Similarly to the request, the second branch of the alternative should be 
employed, I think. So, substituting the  rule:

-> ‘GUID=’’&’
   ‘NAME=’’&’
   ‘PATH=’
   (‘&’ (’=’ | ’=’))*

Which translates to the following response string:

GUID===&=&=&...&=

In a nutshell, I think iPXE should:
- reflect the GUID / NAME / PATH triplet from the input to the output verbatim,
- for each config knob  requested, respond with =.

(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

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Michael Brown]

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?


Thank you,

Michael
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Dong, Eric]

Yes, we can also enhance Hiidatabase to not assert.

From: Ni, Ruiyu
Sent: Thursday, March 31, 2016 8:57 AM
To: Dong, Eric; Laszlo Ersek; Bi, Dandan; Michael Brown
Cc: Justen, Jordan L; edk2-devel-01; Ard Biesheuvel
Subject: RE: HII incompatibility between edk2 and iPXE?

Eric,
Shall we also fix the core driver to not assert when the string is incorrect?

Regards,
Ray

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Dong, 
Eric
Sent: Wednesday, March 30, 2016 11:09 PM
To: Laszlo Ersek <ler...@redhat.com<mailto:ler...@redhat.com>>; Bi, Dandan 
<dandan...@intel.com<mailto:dandan...@intel.com>>; Michael Brown 
<mc...@ipxe.org<mailto:mc...@ipxe.org>>
Cc: Justen, Jordan L 
<jordan.l.jus...@intel.com<mailto:jordan.l.jus...@intel.com>>; edk2-devel-01 
<edk2-de...@ml01.01.org<mailto:edk2-de...@ml01.01.org>>; Ard Biesheuvel 
<ard.biesheu...@linaro.org<mailto:ard.biesheu...@linaro.org>>
Subject: Re: [edk2] HII incompatibility between edk2 and iPXE?

This error is caused by iPXE driver not return the correct string in 
EFI_HII_CONFIG_ACCESS_PROTOCOL.ExtractConfig() function. Base on the spec 
requirement, if the function return success, the Results string should follow 
format. But the data returned by iPXE driver is not follow 
this rule, so the ASSERT raised. Detail can check UEFI spec 2.6 chapter 
33.2.1.5 and 33.5.

Thanks,
Eric
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, March 29, 2016 11:21 PM
To: Bi, Dandan; Dong, Eric; Michael Brown
Cc: edk2-devel-01; Justen, Jordan L; Ard Biesheuvel
Subject: HII incompatibility between edk2 and iPXE?

Hi,

recent edk2 commit 8a45f80edad4 ("MdeModulePkg: Make HII configuration settings 
available to OS runtime") seems to trigger an issue between edk2 and iPXE.

(Note: I'm not saying that 8a45f80edad4 causes the issue, just that it exposes 
it.)

Namely, when you boot a brand new QEMU VM with OVMF (and iPXE presented in the 
NIC's option ROM), then an HII ASSERT() fails. I've come across the issue 
report in 
<https://www.redhat.com/archives/vfio-users/2016-March/msg00153.html>, 
reproduced it, and collected some data to assist with the analysis.

The failed assertion is:

> ASSERT MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c(1256): 
> TmpRequest != ((void *) 0)

Here's the edk2 stack dump:

> #0  0x7fda4070 in CpuDeadLoop ()
> at MdePkg/Library/BaseLib/CpuDeadLoop.c:37
> #1  0x7fda30d5 in DebugAssert (
> FileName=0x7fda47d8 
> "MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c", LineNumber=1256, 
> Description=0x7fda4a20 "TmpRequest != ((void *) 0)")
> at OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c:153
> #2  0x7fd8166f in GetElementsFromRequest (ConfigRequest=0x7898)
> at MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c:1256
> #3  0x7fd8629c in HiiConfigRoutingExportConfig (This=0x7fda9190, 
> Results=0x7ff5e9f0)
> at MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c:4242
> #4  0x7fd90e02 in HiiGetConfigurationSetting (This=0x7fda9138)
> at MdeModulePkg/Universal/HiiDatabaseDxe/Database.c:2815
> #5  0x7fd7c7ae in OnReadyToBoot (Event=0x7f645098, Context=0x0)
> at MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseEntry.c:147
> #6  0x7ff7c785 in CoreDispatchEventNotifies (Priority=8)
> at MdeModulePkg/Core/Dxe/Event/Event.c:200
> #7  0x7ff7bdda in CoreRestoreTpl (NewTpl=4)
> at MdeModulePkg/Core/Dxe/Event/Tpl.c:131
> #8  0x7ff6a030 in CoreReleaseLock (Lock=0x7ff9ac70)
> at MdeModulePkg/Core/Dxe/Library/Library.c:102
> #9  0x7ff7c560 in CoreReleaseEventLock ()
> at MdeModulePkg/Core/Dxe/Event/Event.c:119
> #10 0x7ff7c9cc in CoreNotifySignalList (EventGroup=0x7eeed8d0)
> at MdeModulePkg/Core/Dxe/Event/Event.c:276
> #11 0x7ff7ce60 in CoreSignalEvent (UserEvent=0x7eeed898)
> at MdeModulePkg/Core/Dxe/Event/Event.c:564
> #12 0x7ebe610c in EfiSignalEventReadyToBoot ()
> at MdePkg/Library/UefiLib/UefiNotTiano.c:235
> #13 0x7ebde969 in BdsLibBootViaBootOption (Option=0x7eeecd18, 
> DevicePath=0x7eeeb958,
> ExitDataSize=0x7ff5ed38, ExitData=0x7ff5ed30)
> at IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c:2279
> #14 0x7ebaf0a3 in BdsBootDeviceSelect ()
> at IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c:286
> #15 0x7ebafc1a in BdsEntry (This=0x7ebfbec0)
> at IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c:659
> #16 0x7ff6096a in DxeMain (HobStart=0x7fd14018)
> at MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c:517
> #17 0x7ff5f71d in ProcessModuleEntryPointList (HobStart=0x7bfde000)
> at 
> Build/OvmfX64/DEBUG_GCC48/X64/Mde

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Dong, Eric]

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.

> -Original Message-
> From: Michael Brown [mailto:mc...@ipxe.org]
> Sent: Wednesday, March 30, 2016 11:42 PM
> To: Dong, Eric; Laszlo Ersek; Bi, Dandan
> Cc: edk2-devel-01; Justen, Jordan L; Ard Biesheuvel
> Subject: Re: HII incompatibility between edk2 and iPXE?
> 
> On 30/03/16 16:09, Dong, Eric wrote:
> > This error is caused by iPXE driver not return the correct string in 
> > EFI_HII_CONFIG_ACCESS_PROTOCOL.ExtractConfig() function. Base on
> the spec requirement, if the function return success, the Results string 
> should follow format. But the data returned
> by iPXE driver is not follow this rule, so the ASSERT raised. Detail can 
> check UEFI spec 2.6 chapter 33.2.1.5 and 33.5.
> 
> 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?
> 
> Thanks,
> 
> Michael
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Michael Brown]

On 30/03/16 16:27, Dong, Eric wrote:

I download the iPXE code and check the hii related code. I'm very confused why 
you dynamic generate the ifr data? Why not use vfr file to descript the form 
data? Use vfr file is much easy than dynamic generate it. Also I found you use 
name/value store to save the data, maybe it’s a good choice for your case, but 
it's cost much more effort when implement the EFI Config Access Protocol.


iPXE does not build within the EDK2 build environment.  We use the EDK2 
headers when building EFI binaries, but we don't use any of the EDK2 
build process.


When I first implemented that code in iPXE, I did try to experiment with 
the VFR build process in EDK2, to see if it could be adopted for use in 
iPXE.  I gave up after several frustrating hours of EDK2 build failures 
with incomprehensible error messages.  It was much, much quicker to 
write the code by hand.


Michael
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Michael Brown]

On 30/03/16 16:09, Dong, Eric wrote:

This error is caused by iPXE driver not return the correct string in 
EFI_HII_CONFIG_ACCESS_PROTOCOL.ExtractConfig() function. Base on the spec 
requirement, if the function return success, the Results string should follow 
format. But the data returned by iPXE driver is not follow 
this rule, so the ASSERT raised. Detail can check UEFI spec 2.6 chapter 33.2.1.5 and 
33.5.


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?


Thanks,

Michael
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Dong, Eric]

> On 29/03/16 16:20, Laszlo Ersek wrote:
> > recent edk2 commit 8a45f80edad4 ("MdeModulePkg: Make HII
> configuration settings available to OS runtime") seems to trigger an issue
> between edk2 and iPXE.
> 
> Thanks for debugging this!
> 
> Is iPXE misbehaving here?  At the time that I implemented our HII support,
> the HII_CONFIG_ROUTING_PROTOCOL in EDK2 was so badly broken that I
> couldn't even begin testing with it.  (Any attempt to use it, with or without
> iPXE present, would immediately crash with a NULL pointer dereference, and
> the relevant EDK2 code was so confused that I couldn't even start to guess
> what it was trying to do.)

Yes, where the error is you can check my former mail for this list.

> 
> >>
> gateway===
> =
> >>
> -path==&
> usern
> >> ame
> >
> > Note that my only reason for pointing at iPXE is this result string 
> > precisely.
> Namely, I grepped the edk2 source for various tokens in the above (like
> "scriptlet" and "skip-san-boot"), and came up empty. Then I grepped iPXE for
> the same tokens, and I found them (in "src/usr/autoboot.c"). I think the
> function that actually formats the response string in iPXE is
> efi_snp_hii_extract_config() [src/interface/efi/efi_snp_hii.c].
> 
> Yes, that's where we generate it, and that result string is very plausible 
> for an
> unconfigured iPXE SNP instance.
> 
>  From reading the spec, I can't tell whether what iPXE is doing is correct or
> not.  Any input appreciated.
> 

I download the iPXE code and check the hii related code. I'm very confused why 
you dynamic generate the ifr data? Why not use vfr file to descript the form 
data? Use vfr file is much easy than dynamic generate it. Also I found you use 
name/value store to save the data, maybe it’s a good choice for your case, but 
it's cost much more effort when implement the EFI Config Access Protocol.

> Thanks,
> 
> Michael
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Dong, Eric]

This error is caused by iPXE driver not return the correct string in 
EFI_HII_CONFIG_ACCESS_PROTOCOL.ExtractConfig() function. Base on the spec 
requirement, if the function return success, the Results string should follow 
format. But the data returned by iPXE driver is not follow 
this rule, so the ASSERT raised. Detail can check UEFI spec 2.6 chapter 
33.2.1.5 and 33.5.

Thanks,
Eric
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Tuesday, March 29, 2016 11:21 PM
To: Bi, Dandan; Dong, Eric; Michael Brown
Cc: edk2-devel-01; Justen, Jordan L; Ard Biesheuvel
Subject: HII incompatibility between edk2 and iPXE?

Hi,

recent edk2 commit 8a45f80edad4 ("MdeModulePkg: Make HII configuration settings 
available to OS runtime") seems to trigger an issue between edk2 and iPXE.

(Note: I'm not saying that 8a45f80edad4 causes the issue, just that it exposes 
it.)

Namely, when you boot a brand new QEMU VM with OVMF (and iPXE presented in the 
NIC's option ROM), then an HII ASSERT() fails. I've come across the issue 
report in 
, 
reproduced it, and collected some data to assist with the analysis.

The failed assertion is:

> ASSERT MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c(1256): 
> TmpRequest != ((void *) 0)

Here's the edk2 stack dump:

> #0  0x7fda4070 in CpuDeadLoop ()
> at MdePkg/Library/BaseLib/CpuDeadLoop.c:37
> #1  0x7fda30d5 in DebugAssert (
> FileName=0x7fda47d8 
> "MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c", LineNumber=1256, 
> Description=0x7fda4a20 "TmpRequest != ((void *) 0)")
> at OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c:153
> #2  0x7fd8166f in GetElementsFromRequest (ConfigRequest=0x7898)
> at MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c:1256
> #3  0x7fd8629c in HiiConfigRoutingExportConfig (This=0x7fda9190, 
> Results=0x7ff5e9f0)
> at MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c:4242
> #4  0x7fd90e02 in HiiGetConfigurationSetting (This=0x7fda9138)
> at MdeModulePkg/Universal/HiiDatabaseDxe/Database.c:2815
> #5  0x7fd7c7ae in OnReadyToBoot (Event=0x7f645098, Context=0x0)
> at MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseEntry.c:147
> #6  0x7ff7c785 in CoreDispatchEventNotifies (Priority=8)
> at MdeModulePkg/Core/Dxe/Event/Event.c:200
> #7  0x7ff7bdda in CoreRestoreTpl (NewTpl=4)
> at MdeModulePkg/Core/Dxe/Event/Tpl.c:131
> #8  0x7ff6a030 in CoreReleaseLock (Lock=0x7ff9ac70)
> at MdeModulePkg/Core/Dxe/Library/Library.c:102
> #9  0x7ff7c560 in CoreReleaseEventLock ()
> at MdeModulePkg/Core/Dxe/Event/Event.c:119
> #10 0x7ff7c9cc in CoreNotifySignalList (EventGroup=0x7eeed8d0)
> at MdeModulePkg/Core/Dxe/Event/Event.c:276
> #11 0x7ff7ce60 in CoreSignalEvent (UserEvent=0x7eeed898)
> at MdeModulePkg/Core/Dxe/Event/Event.c:564
> #12 0x7ebe610c in EfiSignalEventReadyToBoot ()
> at MdePkg/Library/UefiLib/UefiNotTiano.c:235
> #13 0x7ebde969 in BdsLibBootViaBootOption (Option=0x7eeecd18, 
> DevicePath=0x7eeeb958,
> ExitDataSize=0x7ff5ed38, ExitData=0x7ff5ed30)
> at IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c:2279
> #14 0x7ebaf0a3 in BdsBootDeviceSelect ()
> at IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c:286
> #15 0x7ebafc1a in BdsEntry (This=0x7ebfbec0)
> at IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c:659
> #16 0x7ff6096a in DxeMain (HobStart=0x7fd14018)
> at MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c:517
> #17 0x7ff5f71d in ProcessModuleEntryPointList (HobStart=0x7bfde000)
> at 
> Build/OvmfX64/DEBUG_GCC48/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/AutoGen.c:423
> #18 0x7ff5f26d in _ModuleEntryPoint (HobStart=0x7bfde000)
> at MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.c:54
> #19 0x in ?? ()

According to my (superficial) tracing, the following happens (see stack frame 
#3 above): the HiiConfigRoutingExportConfig() function in 
"MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c" repeatedly calls 
EFI_HII_CONFIG_ACCESS_PROTOCOL.ExtractConfig(), on drivers / handles that 
export that protocol. Subsequently, each serialized configuration (in the 
output parameter called "AccessResults") is passed to GetElementsFromRequest(), 
in the same C source file.

The GetElementsFromRequest() function asserts that the "PATH=" substring is 
present in the AccessResults string. This assertion breaks down when iPXE 
returns the following result string to HiiConfigRoutingExportConfig():

> gateway==

Note that my only reason for pointing at iPXE is this result string precisely. 
Namely, I grepped the edk2 source for various tokens in the above (like 
"scriptlet" and "skip-san-boot"), and came up empty. Then I grepped iPXE for 
the same tokens, and I found them (in 

Re: [edk2] HII incompatibility between edk2 and iPXE?

[Michael Brown]

On 29/03/16 16:20, Laszlo Ersek wrote:

recent edk2 commit 8a45f80edad4 ("MdeModulePkg: Make HII configuration settings 
available to OS runtime") seems to trigger an issue between edk2 and iPXE.


Thanks for debugging this!

Is iPXE misbehaving here?  At the time that I implemented our HII 
support, the HII_CONFIG_ROUTING_PROTOCOL in EDK2 was so badly broken 
that I couldn't even begin testing with it.  (Any attempt to use it, 
with or without iPXE present, would immediately crash with a NULL 
pointer dereference, and the relevant EDK2 code was so confused that I 
couldn't even start to guess what it was trying to do.)



gateway==


Note that my only reason for pointing at iPXE is this result string precisely. Namely, I grepped the edk2 
source for various tokens in the above (like "scriptlet" and "skip-san-boot"), and came 
up empty. Then I grepped iPXE for the same tokens, and I found them (in "src/usr/autoboot.c"). I 
think the function that actually formats the response string in iPXE is efi_snp_hii_extract_config() 
[src/interface/efi/efi_snp_hii.c].


Yes, that's where we generate it, and that result string is very 
plausible for an unconfigured iPXE SNP instance.


From reading the spec, I can't tell whether what iPXE is doing is 
correct or not.  Any input appreciated.


Thanks,

Michael
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel