Clarification on the LocateDevicePath behavior


valerij zaporogeci
 

Hello, there is a nice requirement for the Boot Manager to understand relative Device Paths, i.e. starting with an HD() node, so that it's still possible to find the loader if the disk has been moved in another port. The loader could do the same, searching for the OS Boot Volume, stored in the FilePath[1] as a relative DP. and my loader does so and it works. it's around 50 lines of code. But then I remembered about LocateDevicePath() and wondered if it can find a handle, if given a relative DP. turns out, it can't. it returns EFI_NOT_FOUND if I want to open BlockIo protocol and feed it a DP of the form HD()\SystemRoot (4.1\4.4).

Did I understand correctly and LocateDevicePath cannot search on short DP forms? Thanks in advance.


valerij zaporogeci
 

Your understanding is correct. LocateDevicePath boot service does not understand short form DP.
The boot manager typically enumerates all the available File systems or Block I/O devices (depending on the context)
and picks the one that matches the short form device path being processed.
Thank you! Sorry, if I reply a wrong way, but I do this through mail,
since in the discussion site https://edk2.groups.io/g/discuss/topics,
your answer hasn't showed up yet.

As a side note, the UEFI specification does not define content or existence of FilePath[1].
EFI_LOAD_OPTION stored in the Boot#### variables always contains FilePath[0],
any other optional device path instances are OS specific.
I know, I meant, that as the Boot Manager processes a short form of
DP, taken from FilePath[0] to find the Loader, as the Loader processes
a short form of DP, taken from FilePath[1] when searching for the OS
System Root. Because of the same advantage to be invariant to the disk
location changes. The presence of the FilePath[1] is required as part
of the OS installation. it is OS specific.

Thank you.


Felix Polyudov
 

Your understanding is correct. LocateDevicePath boot service does not understand short form DP.
The boot manager typically enumerates all the available File systems or Block I/O devices (depending on the context)
and picks the one that matches the short form device path being processed.

As a side note, the UEFI specification does not define content or existence of FilePath[1].
EFI_LOAD_OPTION stored in the Boot#### variables always contains FilePath[0],
any other optional device path instances are OS specific.

-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of valerij zaporogeci via groups.io
Sent: Friday, December 9, 2022 6:09 PM
To: discuss@edk2.groups.io
Subject: [EXTERNAL] [edk2-discuss] Clarification on the LocateDevicePath behavior


**CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.**

Hello, there is a nice requirement for the Boot Manager to understand relative Device Paths, i.e. starting with an HD() node, so that it's still possible to find the loader if the disk has been moved in another port. The loader could do the same, searching for the OS Boot Volume, stored in the FilePath[1] as a relative DP. and my loader does so and it works. it's around 50 lines of code. But then I remembered about LocateDevicePath() and wondered if it can find a handle, if given a relative DP. turns out, it can't. it returns EFI_NOT_FOUND if I want to open BlockIo protocol and feed it a DP of the form HD()\SystemRoot (4.1\4.4).

Did I understand correctly and LocateDevicePath cannot search on short DP forms? Thanks in advance.





-The information contained in this message may be confidential and proprietary to American Megatrends (AMI). This communication is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. Please promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and then delete or destroy all copies of the transmission.