On Tue, Feb 05, 2019 at 01:30:01PM -0800, aaron.yo...@oracle.com wrote: > On 02/04/2019 11:49 AM, aaron.yo...@oracle.com wrote: > > On 01/16/2019 10:54 AM, aaron.yo...@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 > > > > > Ping. Any response to below suggestions? > > > > Thanks, > > > > -Aaron > > > > Note that I do have a new version of the code to add a volume label to the } efimap output (suggestion #2 above), like so: > > > iPXE> efimap > Drive# [Volume Label] Path > ------ ------------------- > 0 [ANACONDA] PciRoot(0x0)/Pci(0x3,0x0)/HD(2,MBR,0x2E0E0369,0xBBC,0x3708) > 1 [DATA DISK3] > PciRoot(0x0)/Pci(0x5,0x0)/HD(1,GPT,F82F29A0-0A75-404F-B0D3-437753C70E75,0x800,0x64000) > 2 [NO VOLUME LABEL] > PciRoot(0x0)/Pci(0x6,0x0)/HD(1,GPT,F82F29A0-0A75-404F-B0D3-437753C70E75,0x800,0x64000) > > And, I have confirmed that when the EFI_DEVICE_PATH_TO_TEXT_PROTOCOL is not > present, the efimap output is like so: > > iPXE> efimap > Drive# [Volume Label] Path > ------ ------------------- > 0 [ANACONDA] > 02010c00d041030a0000000001010600000304012a0002000000bc0b000000000000083700000000000069030e2e0000000000000000000000000101 > 1 [DATA DISK3] > 02010c00d041030a0000000001010600000404012a000100000000080000000000000040060000000000a0292ff8750a4f40b0d3437753c70e750202 > 2 [NO VOLUME LABEL] > 02010c00d041030a0000000001010600000504012a000100000000080000000000000040060000000000a0292ff8750a4f40b0d3437753c70e750202 > > > I could happily resubmit the patches with this new efimap Volume Label > field if that would aid in acceptance.
Not submitting patches will surely not result in acceptance. > Thanks again, > > -Aaron > Groeten Geert Stappers -- Leven en laten leven _______________________________________________ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel