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?

[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 <[email protected]>
| 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 <[email protected]>
| | 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.