uefi: fs: Implement exists #135368

Ayush1325 · 2025-01-11T14:26:40Z

Also adds the initial file abstractions.

The file opening algorithm is inspired from UEFI shell. It starts by classifying if the Path is Shell mapping, text representation of device path protocol, or a relative path and converts into an absolute text representation of device path protocol.

After that, it queries all handles supporting
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL and opens the volume that matches the device path protocol prefix (similar to Windows drive). After that, it opens the file in the volume using the remaining pat.

It also introduces OwnedDevicePath and BorrowedDevicePath abstractions to allow working with the base UEFI and Shell device paths efficiently.

DevicePath in UEFI behaves like an a group of nodes laied out in the memory contiguously and thus can be modeled using iterators.

This is an effort to break the original PR (#129700) into much smaller chunks for faster upstreaming.

rustbot · 2025-01-11T14:26:49Z

r? @jhpratt

rustbot has assigned @jhpratt.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

jhpratt

ping @dvdhrm and @nicholasbishop as UEFI target maintainers. r=me with approval from either of them and the typo fixed.

library/std/src/sys/pal/uefi/fs.rs

nicholasbishop · 2025-01-12T03:20:08Z

There are still quite a few changes in this PR. For better review, could we break it up into some smaller pieces? For example, maybe we could start with a PR that just does some of the device-path helper changes.

Ayush1325 · 2025-01-12T04:09:39Z

There are still quite a few changes in this PR. For better review, could we break it up into some smaller pieces? For example, maybe we could start with a PR that just does some of the device-path helper changes.

Would it be fine to have some dead code with the cfg attribute? I can add the device path abstraction and the file open stuff separately in that case.

This PR is split off from rust-lang#135368 to reduce noise. Signed-off-by: Ayush Singh <ayush@beagleboard.org>

This PR is split off from rust-lang#135368 to reduce noise. No real functionality changes, just some quality of life improvements. Also implement Debug for OwnedDevicePath for some quality of life improvements. Signed-off-by: Ayush Singh <ayush@beagleboard.org>

Ayush1325 · 2025-01-12T04:39:39Z

There are still quite a few changes in this PR. For better review, could we break it up into some smaller pieces? For example, maybe we could start with a PR that just does some of the device-path helper changes.

I have moved the changes to the old DevicePath to a separate PR: #135393

It only contains stuff for OwnedDevicePath, but it should reduce all the noise due to renaming and refactoring from this PR.

This PR is split off from rust-lang#135368 to reduce noise. No real functionality changes, just some quality of life improvements. Introduce `device_path_to_text_raw` which creates a Box<[u16]> (UTF-16 string) from path instead of creating OsString. OsString internally is stored as WTF-8, which means converting OsString to Box<[u16]> requires allocation. This is not ideal for std::fs APIs where we need to perform Device Path Protocol matching while opening a volume, and create a UEFI UTF-16 string from the remaining path (which represents file path inside a volume). This remaining path is never used on the Rust side, and thus does not need to be converted to WTF-8 to be used. By introducing direct conversion to Box<[u16]>, we shorten the conversions from `EFI_DEVICE_PATH_PROTOCOL` -> WTF-8 -> UTF-16 to `EFI_DEVICE_PATH_PROTOCOL` -> UTF-16 which is required in every file open operation. Also implement Debug for OwnedDevicePath for some quality of life improvements. Signed-off-by: Ayush Singh <ayush@beagleboard.org>

This PR is split off from rust-lang#135368 to reduce noise. No real functionality changes, just some quality of life improvements. Introduce `device_path_to_text_raw` which creates a Box<[u16]> (UTF-16 string) from path instead of creating OsString. The UTF-16 returned by `EFI_DEVICE_PATH_TO_TEXT` protocol is owned by the caller, so we are just moving the memory management to box instead of freeing it in the function itself. OsString internally is stored as WTF-8, which means converting OsString to Box<[u16]> requires allocation. This is not ideal for std::fs APIs where we need to perform Device Path Protocol matching while opening a volume, and create a UEFI UTF-16 string from the remaining path (which represents file path inside a volume). This remaining path is never used on the Rust side, and thus does not need to be converted to WTF-8 to be used. By introducing direct conversion to Box<[u16]>, we shorten the conversions from `EFI_DEVICE_PATH_PROTOCOL` -> WTF-8 -> UTF-16 to `EFI_DEVICE_PATH_PROTOCOL` -> UTF-16 which is required in every file open operation. Also implement Debug for OwnedDevicePath for some quality of life improvements. Signed-off-by: Ayush Singh <ayush@beagleboard.org>

This PR is split off from rust-lang#135368 to reduce noise. No real functionality changes, just some quality of life improvements. Introduce `device_path_to_text_raw` which creates a Box<[u16]> (UTF-16 string) from path instead of creating OsString. The UTF-16 returned by `EFI_DEVICE_PATH_TO_TEXT` protocol is owned by the caller, so we are just moving the memory management to box instead of freeing it in the function itself. OsString internally is stored as WTF-8, which means converting OsString to Box<[u16]> requires allocation. This is not ideal for std::fs APIs where we need to perform Device Path Protocol matching while opening a volume, and create a UEFI UTF-16 string from the remaining path (which represents file path inside a volume). This remaining path is never used on the Rust side, and thus does not need to be converted to WTF-8 to be used. By introducing direct conversion to Box<[u16]>, we shorten the conversions from `EFI_DEVICE_PATH_PROTOCOL` -> WTF-8 -> UTF-16 to `EFI_DEVICE_PATH_PROTOCOL` -> UTF-16 which is required in every file open operation. That is, we remove 2 intermediate allocation and 1 UTF-16 validation. Also implement Debug for OwnedDevicePath for some quality of life improvements. Signed-off-by: Ayush Singh <ayush@beagleboard.org>

I am working on fs support for UEFI [0], which similar to windows has prefix components, but is not quite same as Windows. It also seems that Prefix is tied closely to Windows and cannot really be extended [0]. This PR just tries to remove coupling between Prefix and absolute path checking to allow platforms to provide there own implementation to check if a path is absolute or not. I am not sure if any platform other than windows currently uses Prefix, so I have kept the path.prefix().is_some() check in most cases. [0]: rust-lang#135368 [1]: rust-lang#52331 (comment) Signed-off-by: Ayush Singh <ayush@beagleboard.org>

I am working on fs support for UEFI [0], which similar to windows has prefix components, but is not quite same as Windows. It also seems that Prefix is tied closely to Windows and cannot really be extended [1]. This PR just tries to remove coupling between Prefix and absolute path checking to allow platforms to provide there own implementation to check if a path is absolute or not. I am not sure if any platform other than windows currently uses Prefix, so I have kept the path.prefix().is_some() check in most cases. [0]: rust-lang#135368 [1]: rust-lang#52331 (comment) Signed-off-by: Ayush Singh <ayush@beagleboard.org>

This PR is split off from rust-lang#135368 to reduce noise. No real functionality changes, just some quality of life improvements. Introduce `device_path_to_text_raw` which creates a Box<[u16]> (UTF-16 string) from path instead of creating OsString. The UTF-16 returned by `EFI_DEVICE_PATH_TO_TEXT` protocol is owned by the caller, so we are just moving the memory management to box instead of freeing it in the function itself. OsString internally is stored as WTF-8, which means converting OsString to Box<[u16]> requires allocation. This is not ideal for std::fs APIs where we need to perform Device Path Protocol matching while opening a volume, and create a UEFI UTF-16 string from the remaining path (which represents file path inside a volume). This remaining path is never used on the Rust side, and thus does not need to be converted to WTF-8 to be used. By introducing direct conversion to Box<[u16]>, we shorten the conversions from `EFI_DEVICE_PATH_PROTOCOL` -> WTF-8 -> UTF-16 to `EFI_DEVICE_PATH_PROTOCOL` -> UTF-16 which is required in every file open operation. That is, we remove 2 intermediate allocation and 1 UTF-16 validation. Also implement Debug for OwnedDevicePath for some quality of life improvements. Signed-off-by: Ayush Singh <ayush@beagleboard.org>

This PR is split off from rust-lang#135368 to reduce noise. Also implement Debug for OwnedDevicePath for some quality of life improvements. Signed-off-by: Ayush Singh <ayush@beagleboard.org>

This PR is split off from rust-lang#135368 to reduce noise. Rename DevicePath to OwnedDevicePath. This is to allow a non-owning version of DevicePath in the future to work with UEFI shell APIs which provide const pointers to device paths for UEFI shell fs mapping. Also implement Debug for OwnedDevicePath for some quality of life improvements. Signed-off-by: Ayush Singh <ayush@beagleboard.org>

I am working on fs support for UEFI [0], which similar to windows has prefix components, but is not quite same as Windows. It also seems that Prefix is tied closely to Windows and cannot really be extended [1]. This PR just tries to remove coupling between Prefix and absolute path checking to allow platforms to provide there own implementation to check if a path is absolute or not. I am not sure if any platform other than windows currently uses Prefix, so I have kept the path.prefix().is_some() check in most cases. [0]: rust-lang#135368 [1]: rust-lang#52331 (comment) Signed-off-by: Ayush Singh <ayush@beagleboard.org>

…ss35 path: Move is_absolute check to sys::path I am working on fs support for UEFI [0], which similar to windows has prefix components, but is not quite same as Windows. It also seems that Prefix is tied closely to Windows and cannot really be extended [1]. This PR just tries to remove coupling between Prefix and absolute path checking to allow platforms to provide there own implementation to check if a path is absolute or not. I am not sure if any platform other than windows currently uses Prefix, so I have kept the path.prefix().is_some() check in most cases. [0]: rust-lang#135368 [1]: rust-lang#52331 (comment)

This PR is split off from rust-lang#135368 to reduce noise. Rename DevicePath to OwnedDevicePath. This is to allow a non-owning version of DevicePath in the future to work with UEFI shell APIs which provide const pointers to device paths for UEFI shell fs mapping. Also implement Debug for OwnedDevicePath for some quality of life improvements. Signed-off-by: Ayush Singh <ayush@beagleboard.org>

uefi: helpers: Introduce OwnedDevicePath This PR is split off from rust-lang#135368 to reduce noise. No real functionality changes, just some quality of life improvements. Also implement Debug for OwnedDevicePath for some quality of life improvements.

Rollup merge of rust-lang#135405 - Ayush1325:path-is-absolute, r=tgross35 path: Move is_absolute check to sys::path I am working on fs support for UEFI [0], which similar to windows has prefix components, but is not quite same as Windows. It also seems that Prefix is tied closely to Windows and cannot really be extended [1]. This PR just tries to remove coupling between Prefix and absolute path checking to allow platforms to provide there own implementation to check if a path is absolute or not. I am not sure if any platform other than windows currently uses Prefix, so I have kept the path.prefix().is_some() check in most cases. [0]: rust-lang#135368 [1]: rust-lang#52331 (comment)

Rollup merge of rust-lang#135393 - Ayush1325:uefi-helper-path, r=thomcc uefi: helpers: Introduce OwnedDevicePath This PR is split off from rust-lang#135368 to reduce noise. No real functionality changes, just some quality of life improvements. Also implement Debug for OwnedDevicePath for some quality of life improvements.

bors · 2025-01-14T06:53:52Z

☔ The latest upstream changes (presumably #135465) made this pull request unmergeable. Please resolve the merge conflicts.

…asbishop,cuviper uefi: helpers: Add DevicePathNode abstractions - UEFI device path is a series of nodes layed out in a contiguous memory region. So it makes sense to use Iterator abstraction for modeling DevicePaths - This PR has been split off from rust-lang#135368 for easier review. The allow dead_code will be removed in rust-lang#135368 cc `@nicholasbishop`

…bishop,cuviper uefi: helpers: Add DevicePathNode abstractions - UEFI device path is a series of nodes layed out in a contiguous memory region. So it makes sense to use Iterator abstraction for modeling DevicePaths - This PR has been split off from rust-lang#135368 for easier review. The allow dead_code will be removed in rust-lang#135368 cc `@nicholasbishop`

Ayush1325 · 2025-03-17T03:17:45Z

@nicholasbishop This is ready for review now.

library/std/src/sys/fs/uefi.rs

Also adds the initial file abstractions. The file opening algorithm is inspired from UEFI shell. It starts by classifying if the Path is Shell mapping, text representation of device path protocol, or a relative path and converts into an absolute text representation of device path protocol. After that, it queries all handles supporting EFI_SIMPLE_FILE_SYSTEM_PROTOCOL and opens the volume that matches the device path protocol prefix (similar to Windows drive). After that, it opens the file in the volume using the remaining pat. It also introduces OwnedDevicePath and BorrowedDevicePath abstractions to allow working with the base UEFI and Shell device paths efficiently. DevicePath in UEFI behaves like an a group of nodes laied out in the memory contiguously and thus can be modeled using iterators. Signed-off-by: Ayush Singh <ayush@beagleboard.org>

nicholasbishop

lgtm

jhpratt · 2025-03-18T04:24:01Z

@bors r=jhpratt,nicholasbishop

bors · 2025-03-18T04:24:03Z

📌 Commit 2e70cfc has been approved by jhpratt,nicholasbishop

It is now in the queue for this repository.

bors · 2025-03-18T09:09:15Z

⌛ Testing commit 2e70cfc with merge 75530e9...

bors · 2025-03-18T12:17:36Z

☀️ Test successful - checks-actions
Approved by: jhpratt,nicholasbishop
Pushing 75530e9 to master...

github-actions · 2025-03-18T12:19:38Z

This is an experimental post-merge analysis report. You can ignore it.

Post-merge report

What is this?

This is an experimental post-merge analysis report that shows differences in
test outcomes between the merged PR and its parent PR.

Comparing 259fdb5 (parent) -> 75530e9 (this PR)

Test differences

No test diffs found

rust-timer · 2025-03-18T13:50:30Z

Finished benchmarking commit (75530e9): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary -2.9%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-2.9%	[-2.9%, -2.9%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-2.9%	[-2.9%, -2.9%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 776.409s -> 776.359s (-0.01%)
Artifact size: 365.11 MiB -> 365.12 MiB (0.00%)

- UEFI device path is a series of nodes layed out in a contiguous memory region. So it makes sense to use Iterator abstraction for modeling DevicePaths - This PR has been split off from rust-lang#135368 for easier review. The allow dead_code will be removed in rust-lang#135368 Signed-off-by: Ayush Singh <ayush@beagleboard.org>

…bishop,cuviper uefi: helpers: Add DevicePathNode abstractions - UEFI device path is a series of nodes layed out in a contiguous memory region. So it makes sense to use Iterator abstraction for modeling DevicePaths - This PR has been split off from rust-lang#135368 for easier review. The allow dead_code will be removed in rust-lang#135368 cc `@nicholasbishop`

- UEFI device path is a series of nodes layed out in a contiguous memory region. So it makes sense to use Iterator abstraction for modeling DevicePaths - This PR has been split off from rust-lang#135368 for easier review. The allow dead_code will be removed in rust-lang#135368 Signed-off-by: Ayush Singh <ayush@beagleboard.org>

…lasbishop uefi: fs: Implement exists Also adds the initial file abstractions. The file opening algorithm is inspired from UEFI shell. It starts by classifying if the Path is Shell mapping, text representation of device path protocol, or a relative path and converts into an absolute text representation of device path protocol. After that, it queries all handles supporting EFI_SIMPLE_FILE_SYSTEM_PROTOCOL and opens the volume that matches the device path protocol prefix (similar to Windows drive). After that, it opens the file in the volume using the remaining pat. It also introduces OwnedDevicePath and BorrowedDevicePath abstractions to allow working with the base UEFI and Shell device paths efficiently. DevicePath in UEFI behaves like an a group of nodes laied out in the memory contiguously and thus can be modeled using iterators. This is an effort to break the original PR (rust-lang#129700) into much smaller chunks for faster upstreaming.

rustbot assigned jhpratt Jan 11, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jan 11, 2025

jhpratt reviewed Jan 12, 2025

View reviewed changes

library/std/src/sys/pal/uefi/fs.rs Outdated Show resolved Hide resolved

Ayush1325 added a commit to Ayush1325/rust that referenced this pull request Jan 12, 2025

uefi: helpers: Introduce OwnedDevicePath

81a9629

This PR is split off from rust-lang#135368 to reduce noise. Signed-off-by: Ayush Singh <ayush@beagleboard.org>

Ayush1325 mentioned this pull request Jan 12, 2025

uefi: helpers: Introduce OwnedDevicePath #135393

Merged

Ayush1325 mentioned this pull request Jan 12, 2025

path: Move is_absolute check to sys::path #135405

Merged

Ayush1325 force-pushed the uefi-fs-2 branch from 8846387 to 4f2c55d Compare January 12, 2025 19:54

Ayush1325 force-pushed the uefi-fs-2 branch 2 times, most recently from d828ff4 to f4c43cc Compare March 14, 2025 17:39

Ayush1325 requested a review from nicholasbishop March 14, 2025 17:40

nicholasbishop suggested changes Mar 18, 2025

View reviewed changes

library/std/src/sys/fs/uefi.rs Outdated Show resolved Hide resolved

library/std/src/sys/fs/uefi.rs Outdated Show resolved Hide resolved

library/std/src/sys/fs/uefi.rs Outdated Show resolved Hide resolved

Ayush1325 force-pushed the uefi-fs-2 branch from f4c43cc to 894c345 Compare March 18, 2025 02:40

Ayush1325 force-pushed the uefi-fs-2 branch from 894c345 to 2e70cfc Compare March 18, 2025 02:41

Ayush1325 requested a review from nicholasbishop March 18, 2025 02:42

nicholasbishop approved these changes Mar 18, 2025

View reviewed changes

Ayush1325 requested a review from jhpratt March 18, 2025 04:13

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 18, 2025

bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 18, 2025

bors merged commit 75530e9 into rust-lang:master Mar 18, 2025
7 checks passed

rustbot added this to the 1.87.0 milestone Mar 18, 2025

Ayush1325 deleted the uefi-fs-2 branch March 18, 2025 12:23

Ayush1325 mentioned this pull request Mar 20, 2025

Tracking Issue for uefi-std #100499

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

uefi: fs: Implement exists #135368

uefi: fs: Implement exists #135368

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Test differences

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

uefi: fs: Implement exists #135368

uefi: fs: Implement exists #135368

Conversation

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Test differences

Uh oh!

Overall result: no relevant changes - no action needed

Instruction count

Max RSS (memory usage)

Cycles

Binary size

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants