Updating Uefi Raw for EFI Shell Protocol

[RenTrieu]

This PR updates the uefi-raw crate to include the definition for the EFI Shell Protocol as part of the effort to address #448 . Please let me know if there's anything I missed or if there are any improvements I can make!

[phip1611]

Thanks for working on this! 🙌 Just a quick note: we value good git commit hygiene. This doesn't necessarily mean a single commit, but commits should follow this structure:

<component>: <short description>

A more detailed explanation of *what* was done and *why* it was necessary or beneficial.

We can still squash-merge your PR if needed, but I wanted to make you aware of our expectations for future contributions. 🙂

[phip1611]

@nicholasbishop, I think we should use

Suggested change

	command_line: *const Char16,
	command_line: Option<*const Char16>,

here and other optional parameters, right? I know that this is not streamlined across the code base for all OPTIONAL parameters. What do you say?

[nicholasbishop]

uefi-raw should stick close to the C API, so it should not use Option. (Personally I think the UEFI spec should just remove the OPTIONAL annotation, as they use it quite inconsistently and it doesn't have a clear purpose.)

(Also, it wouldn't be compatible with the C ABI unless we also switched from a raw pointer to NonNull. Option<NonNull> is ABI compatible with a raw pointer, but Option<const*> is not, because it can't use the niche optimization.)

[RenTrieu]

Thanks again for your feedback! In general, is the "component" the crate I'm modifying? (e.g. in my case the component would be uefi-raw)?

[phip1611]

Yes, but we are not overly strict. uefi-raw: add EFI Shell protocol might be a good start,

[phip1611]

Also, please rebase your branch onto the latest upstream main when it is ready, rather than merging main into it. Also, it is fine to merge all commits of @timrobertsdev into one, as the commit messages litteraly say to squash them.

In case you need help with git and the necessary steps, feel free to reach out to us!

[RenTrieu]

I believe that I've rebased the branch onto the latest upstream main. I've run the following commands:

git reset --soft <commit of latest upstream/main>
git add -A .
git commit

After which, I would expect to run git push --force.
Does this look right? Also, I'm unclear on how rebasing and force pushing will affect the PR thread on Github. Should I wait for @nicholasbishop to respond on the open comment before pushing?

[phip1611]

git reset --soft <commit of latest upstream/main>
git add -A .
git commit

Ehh, where do you have that from?! The typical workflow is as follows:

git checkout <your branch>
git fetch --all
git rebase upstream/main
<resolve all your possible conflicts and `git rebase --continue` until done)
git push -f

In case something goes wrong on your side, you can undo the rebase using a combination of git reflog and git checkout -f HEAD@{}.

Force-pushing to GitHub is fine, the comments will still be viewable.

[RenTrieu]

Ah, thank you for the recommended commands. I will follow it and push the results shortly. If you don't mind, I do have a follow up question regarding my initial atypical approach. I hope to better understand why the typical workflow is preferred so I can make better contributions in the future.

git reset --soft <commit of latest upstream/main>
git add -A .
git commit

My intent with this was to combine all new commits in this branch into one and then add it back on top of the current main commit. The resulting log would look like:

* commit bb92c1a659ea0af6f135d2cd6de8c9c7c3911a96 (HEAD -> enhancement/efi_shell_protocol_uefi_raw)
| Author: Ren Trieu <ren.trieu.n@gmail.com>
| Date:   Sat May 31 09:25:28 2025 -0700
| 
|     uefi-raw: Add EFI Shell Protocol
|   
*   commit dab0752e393638d8bef93c6d85839b5b04fd1461 (upstream/main, upstream/HEAD)
|\  Merge: d7cec59e 080e87b2
| | Author: Nicholas Bishop <nbishop@nbishop.net>
| | Date:   Thu May 29 19:23:40 2025 +0000
| | 
| |     Merge pull request #1674 from seijikun/mr-safe-pciroot
| |     
| |     uefi: Add (partial) safe protocol implementation for PCI_ROOT_BRIDGE_IO_PROTOCOL
| | 

Is this not preferred because it removes the history? I'm unclear if the result is different from rebasing and then squashing later.

[phip1611]

My intent with this was to combine all new commits in this branch into one and then add it back on top of the current main commit.

Rebasing onto a more recent state and combining commits ("rewriting git history") are two distinct things. Please look at them separately to make things easier.

In your case, one possible path forward would be to:

1. squash your commits into one or fewer using:

• git rebase --interactive HEAD~11 (the number depends on where you want to start the interactive rebase)
• use the s command to squash commits
• ChatGPT will guide you through this with this prompt:

Please create a minimal example (print the git commands with explanation) to do an 
interactive rebase of the past three commits. The commits 2 and 3 should be squashed into the 
first commit

2. rebase onto origin/main afterwards

[RenTrieu]

I see. Thank you for your guidance and patience. I've followed your instruction to squash the commits and then rebase the branch onto upstream/main. Please let me know if the branch now looks alright or if there are still issues I should address.

[phip1611]

yep, well done :) IMHO, you can also squash these three into the first one:

[RenTrieu]

Sounds good! I will squash them together.

[nicholasbishop]

Use the bitflags macro for this type and constants. See for example https://github.com/rust-osdev/uefi-rs/blob/main/uefi-raw/src/protocol/console/serial.rs#L6.

[RenTrieu]

Thank you for the review, @nicholasbishop . I've addressed your comments, but I'm unsure if I've correctly used the bitflags! macro. Would you mind taking a look at my usage?

[RenTrieu]

I've revised the comments relating to ShellDeviceNameFlags. Please let me know if there is anything else I should address.

[nicholasbishop]

Lgtm, thanks!