Or, you could have two pick lists: one near the title of the Orderded List


Boot Order v
  Container 1 v
  Container 2 v
  Container 3 v

That is, "Boot Order" is also a pick list, showing the options that are buffers.

Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Wednesday, September 24, 2014 12:31 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] HII ORDERED_LIST support

I think this sample code is always return UINT8 type, the difference between 
your proposal and my proposal is the "," or " ", just like below
Your proposal:
option text = STRING_TOKEN(0x006F), value = 2, 1, 3, flags = 0;
My proposal:
option text = STRING_TOKEN(0x006F), value = 2  1  3, flags = 0;

I think our proposal both has the same problem which is raised by you.


Also I think if enable option opcode for buffer type, we can't describe it when 
it used in the ordered list op-code. Sample code shows below. do you think so?
If  we support buffer type for option, take below code for example:
      orderedlist
                varid       = MyIfrNVData.BootOrder,
                prompt      = STRING_TOKEN(0x006D),
                help        = STRING_TOKEN(0x0059),
                option text = STRING_TOKEN(0x006F), value = 2, 1, 3, flags = 0;
      endlist;
the result shows like below, how can user to change the order for this case?
             [cid:image004.png@01CFD72D.0304CC60]

Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, September 24, 2014 3:51 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Eric -

The new grammar is ambiguous because it is impossible to tell whether the 
following statement is a UINT8 or a Buffer of size 1.

option text = STRING_TOKEN(0x006F), value = 2, flags = 0;

Since, in my proposal, the behavior of these two value types have different 
behaviors for ORDERED_LIST, it is important to distinguish between them.

Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Thursday, September 04, 2014 8:02 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Tim,

For option, current it only has one value and one prompt string " EFI_STRING_ID 
Option; ". For below example:
      orderedlist
                varid       = MyIfrNVData.BootOrder,
                prompt      = STRING_TOKEN(0x006D),
                help        = STRING_TOKEN(0x0059),
                option text = STRING_TOKEN(0x006F), value = 2, flags = 0;
                option text = STRING_TOKEN(0x006E), value = 1, flags = DEFAULT;
                option text = STRING_TOKEN(0x0070), value = 3, flags = 0;
      endlist;
the result shows like below, and user can change the option order.
[cid:image002.png@01CFD7D4.ED8D1B00]

If  we support buffer type for option, take below code for example:
      orderedlist
                varid       = MyIfrNVData.BootOrder,
                prompt      = STRING_TOKEN(0x006D),
                help        = STRING_TOKEN(0x0059),
                option text = STRING_TOKEN(0x006F), value = 2, 1, 3, flags = 0;
      endlist;
the result shows like below, how can user to change the order for this case?
             [cid:image001.png@01CFD7D4.ED8D1B00]


For the buffer grammar in VFR, because we already has an opcode "ideqvallist" 
which has the similar format, so I follow this style to define the buffer 
grammar.
  numeric varid   = MyIfrNVData.HowOldAreYouInYearsManual,
            prompt  = STRING_TOKEN(STR_NUMERIC_MANUAL_PROMPT),
            help    = STRING_TOKEN(STR_NUMERIC_HELP0),
            minimum = 0,
            maximum = 0xf0,
            step    = 0,
            default value = questionrefval(devicepath = STRING_TOKEN 
(STR_DEVICE_PATH), guid = DRIVER_SAMPLE_FORMSET_GUID, 0x1111),

            inconsistentif prompt = STRING_TOKEN(STR_ERROR_POPUP),
              ideqval MyIfrNVData.HowOldAreYouInYearsManual == 99
              OR
              ideqid  MyIfrNVData.HowOldAreYouInYearsManual == MyEfiVar.Field8
              OR
              ideqvallist MyIfrNVData.HowOldAreYouInYearsManual == 1 3 5 7
            endif
endnumeric;


      orderedlist
                varid       = MyIfrNVData.BootOrder,
                prompt      = STRING_TOKEN(0x006D),
                help        = STRING_TOKEN(0x0059),
                option text = STRING_TOKEN(0x006F), value = 2  1  3, flags = 0;
      endlist;

Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Friday, September 05, 2014 8:09 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Eric -

Here is the basic idea:

typedef struct _EFI_IFR_ONE_OF_OPTION {
  EFI_IFR_OP_HEADER Header;
  EFI_STRING_ID Option;
  UINT8 Flags;
  UINT8 Type;  <<= For ORDERED_LIST, can be EFI_IFR_TYPE_NUM_SIZE_8 or 
EFI_IFR_TYPE_BUFFER
  EFI_IFR_TYPE_VALUE Value;
} EFI_IFR_ONE_OF_OPTION;

typedef struct _EFI_IFR_DEFAULT {
  EFI_IFR_OP_HEADER Header;
  UINT16 DefaultId;
  UINT8 Type;  <<= For ORDERED_LIST, can be EFI_IFR_TYPE_NUM_SIZE_8 or 
EFI_IFR_TYPE_BUFFER
  EFI_IFR_TYPE_VALUE Value;
} EFI_IFR_DEFAULT;

For EFI_IFR_ORDERED_LIST only, the nested EFI_IFR_ONE_OF_OPTION can be either 
EFI_IFR_TYPE_NUM_SIZE_8 or EFI_IFR_TYPE_BUFFER. If it is 
EFI_IFR_TYPE_NUM_SIZE_8, then the option value is only for a single container. 
But if it is EFI_IFR_TYPE_BUFFER, then it is for all containers. If 
EFI_IFR_TYPE_BUFFER and the number of bytes is smaller than the number of 
containers, then remaining containers are set to 0 (empty)

Same with EFI_IFR_DEFAULT.

BTW, I suggest that the buffer grammar in VFR be "{" byte-list "}"  and 
byte-list := <byte-list "," integer> | integer

Tim



From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Wednesday, September 03, 2014 6:31 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Tim,

Add my comments below.


From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Thursday, September 04, 2014 12:04 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Eric -

Here is what I am thinking: we can extend the UEFI specification (which I will 
do in a separate ECR), to allow either the UINT8 or the BUFFER value for 
"option" and "default" If UINT8, then it will work on a single container. If 
BUFFER then it works on all containers. It may take me a week (after IDF) to 
get the ECR written for UEFI.
[[[Eric]]] If in BUFFER type, we can create a sample like below. In this case, 
only one "text" for this option, how to show the different value for this 
orderedlist? Maybe we need to update the "text" field also? I agree it has 
value to support BUFFER type for default opcode, because in this case we can 
set default value for "orderedlist" opcode. But I don't know the value to 
support BUFFER for "option"? It will make the "option" more complicate to 
handle. Also the "option" can be used for "Oneof" opcode, we also need consider 
this opcode when we clarify the "option" opcode.
      orderedlist
                varid       = MyIfrNVData.BootOrder,
                prompt      = STRING_TOKEN(0x006D),
                help        = STRING_TOKEN(0x0059),
                option text = STRING_TOKEN(0x006F), value = 2  1  3, flags = 0;
      endlist;

I think that if we document this behavior, it will be useful.

Are there any other question types where there are multiple value types 
possible? Obviously UINTx. How about CHECKBOX with integer? Or NUMERIC with 
BOOLEAN? Just thinking ahead.
[[[Eric]]] I think we don't have that question.

Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Tuesday, September 02, 2014 10:45 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

After internal discussion, we agree default opcode can support ordered list 
opcode, I will follow up to enable it.

For your proposal, item 2 I think it's not an acceptable proposal, take below 
code for example:
      orderedlist
                varid       = MyIfrNVData.BootOrder,
                prompt      = STRING_TOKEN(0x006D),
                help        = STRING_TOKEN(0x0059),
                option text = STRING_TOKEN(0x006F), value = 2, flags = 0;
                option text = STRING_TOKEN(0x006E), value = 1, flags = DEFAULT;
                option text = STRING_TOKEN(0x0070), value = 3, flags = 0;
      endlist;
normally, we can see option 2/option 1/option 3 for this ordered list. But base 
on your proposal, the default for this ordered list opcode is option 1/option 
1/option 1, do you think  this is an valid ordered list result? I think if 
DEFAULT flag is set, we can just skip this flag. We can use default opcode to 
set default for ordered list opcode.

For your proposal, I think you can submit an ECR for it.

Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, September 03, 2014 10:24 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Again, these are EDK2 decisions. They are not limitations of the specification. 
The UEFI specification does not indicate that the EFI_IFR_ONE_OF_OPTION default 
flag cannot work for ordered list. The UEFI specification does not say that 
there is any limitation to the default opcode. It does not say that 
EFI_IFR_TYPE_BUFFER cannot be used.   These are EDK2 and VFR limitations, not 
specification limits.

So, that is why I made the proposal below: to try and clarify the behavior if 
these exist based on the UEFI specification language.

Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Tuesday, September 02, 2014 7:10 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

For ordered list opcode, we not support set default flags in the option field. 
It is useful for oneof opcode not for ordered list opcode. Also I think your 
proposal of item 2) also not acceptable. We not support set default value 
through option for ordered list opcode.

The value for ordered list opcode is buffer type, but the default opcode not 
support save buffer type value(The EFI_IFR_TYPE_VALUE not support buffer type), 
so the default opcode can't be used by ordered list opcode.
[cid:image003.jpg@01CFD7D4.ED8D1B00]

[cid:image004.jpg@01CFD7D4.ED8D1B00]

Current for ordered list opcode, browser based on the current option order nest 
in this question to set the default value for it.
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, September 03, 2014 5:32 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Eric -

I believe that what you say is useful. But I don't think the specification 
describes that behavior.

The next question, which was asked by someone else on the EDK2 list, is what to 
do with "default" Both the flag for the "option" and the separate "default" 
opcode. The "just the value for the one container" does not seem like a good 
usage for default, since normally the engineer would like to saw the default 
values for all containers. But if "option" is for 1 container, then how does 
that work for default?

So here is a proposal for a clarification I would like to see in the UEFI 
specification:


1)      That, for ordered list, the "option values" should refer to a single 
container.

2)      When setting the default value using "option" then all containers will 
be filled with that value.

3)      When setting the default value using "default" then the "value" will be 
a Buffer type, with one byte of the Buffer per container. If the default value 
is smaller than the Buffer size, then the remaining containers will be filled 
with 0.

Tim


From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Monday, September 01, 2014 6:40 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Tim,

I admit that one container should only has one byte, and I think one option is 
corresponding to one container, do you agree this assumption?

For below sample code, current code use UINT16 for BootOrder array, so the 
value for each option is UINT16. Now I think we should not use UINT16 array for 
ordered list,  we should only user BYTE type(UINT8) array for the ordered list 
opcode. Right?
                varid       = MyIfrNVData.BootOrder,
                prompt      = STRING_TOKEN(0x006D),
                help        = STRING_TOKEN(0x0059),
                option text = STRING_TOKEN(0x006F), value = 2, flags = 
RESET_REQUIRED;
                option text = STRING_TOKEN(0x006E), value = 1, flags = 
RESET_REQUIRED;
                option text = STRING_TOKEN(0x0070), value = 3, flags = 
RESET_REQUIRED;
              suppressif ideqval MyIfrNVData.BootOrderLarge == 0;
                option text = STRING_TOKEN(0x0071), value = 4, flags = 
RESET_REQUIRED;
              endif
      endlist;

typedef struct {
  ...
  UINT16  BootOrder[8];
  ...
} DRIVER_SAMPLE_CONFIGURATION;


Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Tuesday, September 02, 2014 9:25 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Eric -

It is pretty clear from the spec that the value size for ordered list is 1 byte 
per container. See 29.2.5.4.8,

"Storage The set questions are stored as a Buffer with one byte for each 
Container."

There is no indication, either in the IFR or VFR specification that "option" 
values refer to  a single container value. There is also no indication in these 
specifications that an option is a 16-bit value.

Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Monday, September 01, 2014 6:18 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Tim,

I agree "Value of the question is the entire buffer, not just one byte." But I 
don't think "the value in a ONE_OF_OPTION is the value for the entire value 
storage, not just one byte of the value storage. "
Take below code for example, the value for this question is 0002,0001,0003,0004 
(8 byte), and the value type if buffer type. but for each option, the value is 
different(0002/0001/0003/004), and type is UINT16 (2 byte), not 8 byte.
      orderedlist
                varid       = MyIfrNVData.BootOrder,
                prompt      = STRING_TOKEN(0x006D),
                help        = STRING_TOKEN(0x0059),
                option text = STRING_TOKEN(0x006F), value = 2, flags = 
RESET_REQUIRED;
                option text = STRING_TOKEN(0x006E), value = 1, flags = 
RESET_REQUIRED;
                option text = STRING_TOKEN(0x0070), value = 3, flags = 
RESET_REQUIRED;
              suppressif ideqval MyIfrNVData.BootOrderLarge == 0;
                option text = STRING_TOKEN(0x0071), value = 4, flags = 
RESET_REQUIRED;
              endif
      endlist;

so I think current issue for vfrcompile is it not restrict the data type for 
each container is 1 byte.

Thanks,
Eric
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Monday, August 25, 2014 3:11 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Eric -

For #1, this seems like a VFR compiler error, since the Form Browser does not 
place the container value in each element of the array (if the array is UINT16)

For #2, please refer to section 29.2.5.4.8, where it says:

"Storage The set questions are stored as a Buffer with one byte for each 
Container."

Then also see 29.2.5.4.1: "Question values are a data type listed in Section 
29.2.5.7.4." For an ordered list, the value is a Buffer (not one byte in a 
buffer) See also the Callback for CHANGING/CHANGED where the Ordered List value 
should be a buffer. The defaults 29.2.5.8 says "Defaults are pre-defined 
question values." Options say they "give ...description of a particular 
question value" (29.2.5.5)

This means that the Value of the question is the entire buffer, not just one 
byte.

Consider this case: I want to set the default boot order to 5,6,7,8,0,2,4. I 
understand that it is useful to see the value as one byte, and this might work 
best for one-of, but not for default. In any case, either the Form Browser 
needs to be changed or the specification needs to be changed for the 
ordered-list case.

Tim

From: Dong, Eric [mailto:eric.d...@intel.com]
Sent: Monday, August 25, 2014 2:40 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] HII ORDERED_LIST support

Tim,

Add my comments below.

From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Friday, August 22, 2014 12:40 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: [edk2] HII ORDERED_LIST support

In DriverSampleDxe, the boot order item is listed in storage as:

  UINT16  BootOrder[8];

And here is the ordered list which manipulates this item:

      orderedlist
                varid       = MyIfrNVData.BootOrder,
                prompt      = STRING_TOKEN(0x006D),
                help        = STRING_TOKEN(0x0059),
                option text = STRING_TOKEN(0x006F), value = 2, flags = 
RESET_REQUIRED;
                option text = STRING_TOKEN(0x006E), value = 1, flags = 
RESET_REQUIRED;
                option text = STRING_TOKEN(0x0070), value = 3, flags = 
RESET_REQUIRED;
              suppressif ideqval MyIfrNVData.BootOrderLarge == 0;
                option text = STRING_TOKEN(0x0071), value = 4, flags = 
RESET_REQUIRED;
              endif
      endlist;

This leads to a number of questions:


1)      The BootOrder is defined as UINT16, but the UEFI specification clearly 
states that an orderedlist will work on a buffer with one byte per container.  
(See 29.2.5.4.8 where it says, "The set questions are stored as a Buffer with 
one byte for each Container."

[[[Eric]]] Truly spec has this description but vfrcompile and browser not do 
this check, also current code may already has samples which already violate 
this rule, so I need more discussion to provide a good proposal for this case.



[TIM] I am not worried about the actual struct members. BootOrder is 16 bytes 
(8 x sizeof(UINT16). So that means that MaxContainers will be 16, right? The 
VFR spec says: "NOTE: maxcontainers is optional, and the default value depends 
on the variable size defined by varid in vfrQuestionHeader" So it seems that, 
even though the code will work, using UINT8

BootOrder[16] would be easier to understand than UINT16 BootOrder[8]"

[[[Eric]]] Base on current implementation, the maxcontainer value is the array 
size. So for "UINT16 BootOrder[8]", the maxcontainer = 8 and for "UINT8 
BootOrder[16]", the maxcontainer = 16. I think we need to add check for the 
code first, only support one byte for each container.



2)      The option values are all integers. But the storage type of an ordered 
list is a BUFFER. To me this implies (I haven't looked this up) that the value 
an option is being used as the option for a single container. That makes sense, 
but it is not the behavior described in the UEFI specification. Also, there 
seems to be no way to create a value for a question of type buffer.

[[[Eric]]] no catch what's your mean is.

[TIM] For example, for "oneof" the value storage size is UINT8/UINT16/UINT32 or 
UINT64. The value storage size for "checkbox" is BOOLEAN. But what is the value 
storage size of "orderedlist" When I read the UEFI specification, the "value 
storage size" of orderedlist is maxcontainers x sizeof(UINT8). So, if 
maxcontainers is 16, then 16 bytes. BUT: the size of the value in an "option" 
inside the "orderedlist" in these examples is sizeof(UINT8), not maxcontainers 
x sizeof(UINT8).



According to the UEFI specification, as I read it today, the value in a 
ONE_OF_OPTION is the value for the entire value storage, not just one byte of 
the value storage.  So every container  in the ordered list value should be set 
to 2 when the first "ONE_OF_OPTION" (in the example above) is selected by the 
user.

[[[Eric]]] I can't find this information from the spec, which page in UEFI spec 
2.4b describe it?



But I do not believe this is what the EDK2 Form browser does today. I believe 
that it only changes a single container to the value 2 (not the whole buffer).



3)      Likewise, there seems to be no way to provide a default for an ordered 
list.

[[[Eric]]] yes, ordered list opcode just base on the current option order to 
set the default value. For your above example, the default value is 2,1,3,4.



[TIM] If I put a "default = 2" in the example above, will it set one container 
to "2" or all containers to "2" Again, this is a problem with the way the 
specification describes values for ordered list opcodes. It is fairly clear 
that the EDK2 form browser takes a different approach than the current 
specification.



Here is an example display:



Boot Order: [boot order 1] [boot order 2][boot order 3][boot order 4][boot 
order 5][boot order 6][boot order 7][boot order 8]



Each [boot order x] is a container. If the user goes to [boot order 2] and uses 
one of the ONE_OF_OPTION pre-defined values, does it change only [boot order 2] 
or all [boot order x]?  Now, what does the UEFI specification say should happen?

[[[Eric]]] what's your mean of "uses one of the ONE_OF_OPTION pre-defined 
values"?  for ordered list opcode, we can only change the order of the options, 
can't only select one option, I don't know your means about this sample?

Tim
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Reply via email to