[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