[if gte mso 9]>

Re: [edk2] Hii and EFI Variables

Subject: Re: [edk2] Hii and EFI Variables

From: "Dong, Eric" <eric.dong@intel.com>

To: "edk2-devel@lists.sourceforge.net" <edk2-devel@lists.sourceforge.net>

Date: 2013-11-14 10:53:50

Ben,

 

For your situation, I think varstore is good for you.

For the varstore definition, you can see the DriverSample code in MdeModulePkg/Universal/DriverSampleDxe. For how to maintain varstore storage, browser will call ExtractConfig/RouteConfig function provide by your driver to get /set value for your driver. How you get/set storage in your driver is totally decide by you. In driver sample code, we just save to the variable for varstore. But for your driver, you can save to anywhere else.

 

Thanks,

Eric

From: Ben Schroeder [mailto:bensch@mellanox.com]
Sent: Thursday, November 14, 2013 12:38 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Hii and EFI Variables

 

Tim,

 

I mean I do not use EFI Var Store. I am however using Buffer Var Store as my VFR storage.

Also, I do not use an EFI variable locally to save the data.
So I wasn’t sure what GUID it was expecting in the <ConfigResp>, since I don’t have a GUID from neither EFI Var Store, nor from local EFI variables.

 

The Name Value Var store seems to suite my needs better. However from the examples I see, the parsing for these name/value pairs seems pretty long (code wise).

This would even be worse for me since I am supporting many variables..

I will read more about this storage type because it seems good for what I need.

 

Thanks,

Ben.

 

From: Tim Lewis [mailto:tim.lewis@insyde.com]
Sent: Wednesday, November 13, 2013 4:15 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Hii and EFI Variables

 

Ben –

 

When you say “I do not use a Var Store” what do you mean? Why not use a NAME_VALUE var store, instead of the traditional buffer var store? The Name Value does not even assume that it is a bucket of bytes (thus, no offsets).

 

Actually, the Form Browser does not (for the most part) save anything to UEFI variables, that is the responsibility of the driver. So you can decide when, if and how much of the data comes from a UEFI variable.

 

Tim

 

From: Ben Schroeder [mailto:bensch@mellanox.com]
Sent: Wednesday, November 13, 2013 7:44 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Hii and EFI Variables

 

Eric,

 

In ExtractConfig function of HII config access protocol, I am required to return a <ConfigResp>

This header includes the following 3 fields:

<GuidHdr> ::= ‘GUID=’<Guid>

<NameHdr> ::= ‘NAME=’<String>

<PathHdr> ::= ‘PATH=’<UEFI binary Device Path represented as hex

number>

 

Assuming I do not use a Var Store, but decide to save data locally –

How should I fill the GUID and Name fields?

 

Thanks,

Ben.

 

From: Dong, Eric [mailto:eric.dong@intel.com]
Sent: Friday, November 08, 2013 4:11 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Hii and EFI Variables

 

Ben,

 

Add my comments below.

 

Thanks,

Eric

From: Ben Schroeder [mailto:bensch@mellanox.com]
Sent: Thursday, November 07, 2013 11:53 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Hii and EFI Variables

 

Let me clarify my third question:

The example shows code that when receiving a NULL <ConfigRequest> request string in ExtractConfig, will build a <ConfigHdr>.

This <ConfigHdr> will be used to construct a <ConfigResp> response string that holds the fields and data of this VFR Form, needed by ExtractConfig().

I would like to continue to support this option of NULL request strings, but stop using EFI Variables.

Because the function HiiConstructConfigHdr accepts a GUID as a parameter, I am not sure if it would still be possible.

If so, what GUID and Name would I pass to HiiConstructConfigHdr  function so that I may continue support this feature?

 

Thanks,

Ben

From: Ben Schroeder [mailto:bensch@mellanox.com]
Sent: Thursday, November 07, 2013 5:39 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] Hii and EFI Variables

 

Hi,

 

First Question:

The examples I have seen for HII Config Access Protocol have used an EFI Variable to store the data and retrieve it.

Is it possible to just use a defined structure and set/get the values from it.

 

It doesn’t seem that GetVariable/SetVariable are necessary if I can just save the values in a struct for my driver use.

Then I can pass these values to BlockToConfig as needed.

 

Is this possible? Is there anything that requires me to use EFI variables in junction with HII config access protocol.

[[[Eric]]] It’s ok, ExtractConfig/RouteConfig is used by browser to save/get data for Hii driver, hii driver can decide where to save the data. It just need to make sure the data can save and retrieve.

 

 

Second Question (about HiiConstructConfigHdr):

EFIAPI

HiiConstructConfigHdr (

  IN CONST EFI_GUID  *Guid,  OPTIONAL

  IN CONST CHAR16    *Name,  OPTIONAL

  IN EFI_HANDLE      DriverHandle

  )

 

It takes a Guid and a Name. I assume this is the GUID of an EFI var store, otherwise why would you need a name?

Or is it the GUID of the VFR Form?

[[[Eric]]] When you define a varstore, you need to input the guid and name, there are the tags for this varstore. Here your input are the guid and name for this varstore.

 

 

Last Question: (concerning ExtractConfig() from ConfigAccessProtocol)

 

The following code is taken from DriverSampleDxe.

Assuming I don’t use EFI Variables.  I also assume I would still need take care of the even of a NULL request string, and populate the entire configuration header.

How what I go about this if I don’t use EFI VarStore? (assuming it’s not necessary to work with HII)

 

  if (Request == NULL) {

    //

    // Request is set to NULL, construct full request string.

    // Allocate and fill a buffer large enough to hold the <ConfigHdr> template

    // followed by "&OFFSET=0&WIDTH=WWWWWWWWWWWWWWWW" followed by a Null-terminator

    //

    ConfigRequestHdr = HiiConstructConfigHdr (&gDriverSampleFormSetGuid, VariableName, PrivateData->DriverHandle[0]);

    Size = (StrLen (ConfigRequestHdr) + 32 + 1) * sizeof (CHAR16);

    ConfigRequest = AllocateZeroPool (Size);

    ASSERT (ConfigRequest != NULL);

    AllocatedRequest = TRUE;

    UnicodeSPrint (ConfigRequest, Size, L"%s&OFFSET=0&WIDTH=%016LX", ConfigRequestHdr, (UINT64)BufferSize);

    FreePool (ConfigRequestHdr);

    ConfigRequestHdr = NULL;

  }

[[[Eric]]] The guid and name is the varstore tags.

 

Thanks,

Ben.