[ipxe-devel] [PATCH 0/4] Local UEFI disk boot support

[aaron.young at oracle.com]

On 01/15/2019 06:23 AM, Michael Brown wrote:
> On 09/01/2019 19:35, Aaron Young wrote:
>> Example output of the efimap command is as follows:
>>
>> iPXE> efimap
>> Drive#    Path
>> ------    ----
>> 0 PciRoot(0x0)/Pci(0x3,0x0)/HD(2,MBR,0x2E0E0369,0xBBC,0x3708)
>> 1 PciRoot(0x0)/Pci(0x4,0x0)/HD(1,GPT,F82F29A0-...,0x800,0x64000)
>> 2 PciRoot(0x0)/Pci(0x5,0x0)/HD(1,GPT,F82F29A0-...,0x800,0x64000)
>> 3 PciRoot(0x0)/Pci(0x6,0x0)/HD(1,GPT,F82F29A0-...,0x800,0x64000)
>> 4 PciRoot(0x0)/Pci(0x7,0x0)/HD(1,GPT,F82F29A0-..,0x800,0x64000)
>
> It's reasonably common to have UEFI systems that do not provide 
> EFI_DEVICE_PATH_TO_TEXT_PROTOCOL, which is why efi_devpath_text() is 
> used only in DBG() statements.
>
> How is this feature expected to behave (both in terms of drive 
> ordering and in terms of efimap output) if the protocol is not available?
>
> Thanks,
>
> Michael

  Thanks for the review.

  That's a good point. I didn't realize DEVICE_PATH_TO_TEXT protocol was 
commonly not provided (it's part of the UEFI spec - section 10.6).

  Currently, the code (i.e. efi_devpath_text()), when there's no 
DEVICE_PATH_TO_TEXT protocol, will use a raw hex string as the text (via 
base16_encode()):

<snip>
     /* If we have no DevicePathToText protocol then use a raw hex string */
     if ( ! efidpt ) {
         DBG ( "[No DevicePathToText]" );
         len = efi_devpath_len ( path );
         base16_encode ( path, len, text, sizeof ( text ) );
         return text;
     }
<\snip>


  So, the code still works, it just isn't very user friendly.

  Do you have a suggestion on how to rectify this?

  Seems we could either:

1. leave code as is - i.e. on systems with no provided protocol, they 
get ugly raw not-humanly-readable hex strings.
2. Add a volume label field to the efimap output which may help in 
identifying/distinguishing the HDDs.
3. Include DEVICE_PATH_TO_TEXT protocol implementation directly in iPXE 
(or a simplified version of it) for use when the protocol isn't available.

  Do you have a preference?

  Thanks,

  -Aaron