Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

uefi: Implement getcwd and chdir #129794

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Ayush1325
Copy link
Contributor

  • Using EFI Shell Protocol. These functions do not make much sense unless a shell is present.
  • Return the exe dir in case shell protocol is missing.

r? @joboet

@rustbot 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 Aug 30, 2024
@Ayush1325 Ayush1325 changed the title Implement getcwd and chdir uefi: Implement getcwd and chdir Aug 30, 2024
@Ayush1325 Ayush1325 force-pushed the uefi-os-expand branch 2 times, most recently from 0d0e44f to 48dd6a3 Compare August 31, 2024 08:14
@bors
Copy link
Contributor

bors commented Sep 23, 2024

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

- Using EFI Shell Protocol. These functions do not make much sense
  unless a shell is present.
- Return the exe dir in case shell protocol is missing.

Signed-off-by: Ayush Singh <[email protected]>
@Ayush1325
Copy link
Contributor Author

ping @joboet

@joboet
Copy link
Member

joboet commented Oct 10, 2024

I'm very sorry for not getting back to you sooner.

The problem I see here is that GetCurDir returns a mapping, not a device path and will therefore not interoperate with our current filesystem implementation. I think there are two options we could take here:

  1. Normalize the mapping to a device path using GetDevicePathFromMap
  2. Use the filesystem functions from UEFI shell when available, which support both mappings and device paths.

Option 2 is more work, but has the advantage that File would support opening paths stored in environment variables, which will probably be mappings, not device paths, so I think that is the best option in the long run. If you want to get this PR merged first, then option 1 would also be fine for now.

@Ayush1325
Copy link
Contributor Author

Ayush1325 commented Oct 10, 2024

I'm very sorry for not getting back to you sooner.

It's fine. Everyone is doing stuff in their free time after all.

The problem I see here is that GetCurDir returns a mapping, not a device path and will therefore not interoperate with our current filesystem implementation. I think there are two options we could take here:

  1. Normalize the mapping to a device path using GetDevicePathFromMap
  2. Use the filesystem functions from UEFI shell when available, which support both mappings and device paths.

Option 2 is more work, but has the advantage that File would support opening paths stored in environment variables, which will probably be mappings, not device paths, so I think that is the best option in the long run. If you want to get this PR merged first, then option 1 would also be fine for now.

Thanks for pointing it out. I will add a TODO to implement it in the fs PR. Having support for mappings in file i/o is essential.

Personally, I would like to stick to the normal UEFI file APIs, and add plumbing in Rust side to handle the mapping to device path. It is fairly simple to do since we have edk2 as reference.

@joboet
Copy link
Member

joboet commented Oct 13, 2024

Right, then let's ship this.
@bors r+

@bors
Copy link
Contributor

bors commented Oct 13, 2024

📌 Commit 1f718f9 has been approved by joboet

It is now in the queue for this repository.

@bors 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 Oct 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants