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

aaron.young at oracle.com aaron.young at oracle.com
Mon Feb 4 19:49:14 UTC 2019


Ping. Any response to below suggestions?

Thanks,

  -Aaron

On 01/16/2019 10:54 AM, aaron.young at oracle.com wrote:
>
>
> 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
>
>
> _______________________________________________
> ipxe-devel mailing list
> ipxe-devel at lists.ipxe.org
> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel




More information about the ipxe-devel mailing list