-
-
Notifications
You must be signed in to change notification settings - Fork 170
Enhancement/efi shell interface #1679
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
base: main
Are you sure you want to change the base?
Enhancement/efi shell interface #1679
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this! As a general rule of thumb: High-level wrappers should be close to the API of std
and not replicate "ugly" or unusual details of the low-level API. See my suggestions for get_var
Some general guidance:
|
Thanks for the feedback! I will start with making the PR to update |
This commit implements wrappers for the following EFI Shell Protocol functions: set_env(), get_env(), set_cur_dir(), and get_cur_dir().
This commit includes tests for the following EFI Shell Protocol functions: get_env(), set_env(), get_cur_dir(), and set_cur_dir().
Hi all. Now that #1680 is merged, I was wondering if it would be alright to use this PR to work on the 4 ergonomic wrappers I've implemented ( If it is okay to continue to use this PR, then I plan to rebase this branch onto the current main, squash the commits, and then continue from there. |
That sounds good, start with doing that in this PR. Once the changes are in this PR it's possible I might ask for it to be split up into more than one PR for review, but we can start with the assumption that one PR is OK. |
b9a3be8
to
0f30078
Compare
I've rebased this branch onto the current main and updated it to disclude the |
The UEFI get_env() implementation is used for getting individual environment variable values and also environment variable names. This is not intuitive so this commit splits the function into two dedicated ones: one for accessing values and the other for accessing names.
Co-authored-by: Philipp Schuster <[email protected]>
36f37cc
to
910e291
Compare
910e291
to
42cad4a
Compare
Thanks for the feedback! I have updated
to represent the
instead, but I don't see this function implemented for I'll start working on unit tests next! However, for Miri I will need to take some time to read its docs since I'm not familiar. |
|
||
/// Contains environment variables | ||
#[derive(Debug)] | ||
pub struct Vars<'a> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great! Please also add a regular unit test for it. You can mock the corresponding data structure using something like:
let mut vars_mock = Vec::<u16>::new();
vars_mock.push(b'H' as u16);
vars_mock.push(b'i' as u16);
vars_mock.push(0);
vars_mock.push(b'B' as u16);
vars_mock.push(b'y' as u16);
vars_mock.push(b'e' as u16);
vars_mock.push(0);
vars_mock.push(0);
uefi-test-runner/src/proto/shell.rs
Outdated
|
||
/* Test setting and getting a specific environment variable */ | ||
let cur_env_vec = shell.get_envs(); | ||
let mut test_env_buf = [0u16; 32]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no need for these buffers anymore ;)
Co-authored-by: Philipp Schuster <[email protected]>
5661358
to
6b35e5a
Compare
This PR will implement the wrappers for EFI Shell Protocol functions to address #448 . This PR does branch off of the changes made in #596 so big thanks to @timrobertsdev for laying the groundwork!
Currently, I've implemented wrappers and wrote tests for
GetEnv()
,SetEnv()
,GetCurDir()
andSetCurDir()
. My plan is to first write tests for and finish implementingExecute()
,CloseFile()
,CreateFile()
,FindFiles()
,FindFilesInDir()
, andGetFileSize()
since they have already been started. Then I can implement the rest in either this PR or subsequent follow up PRs (whichever is preferable).I do have some questions about my
get_env()
implementation. UEFI'sGetEnv()
returns the value of a variable if its name is specified. However if its name is not specified, it returns all known variable names in a*const Char16
where the names are delimited by aNULL
and the end of the list is terminated by a doubleNULL
.My initial approach was to parse the
*const Char16
into aVec
in this case. I wrapped the return value in an Enum that can be unpacked into a single&CStr16
or into a vector of&CStr16
s depending on which is expected. Is this approach okay? I was concerned that if I simply returned a&CStr16
in the "name list" case that the true size of the string wouldn't be visible since the names are separated byNULL
. Also, is it okay for me to usealloc::vec::Vec
? I saw that a lot of other protocols don't use anyVec
at all so I'm not clear on if there are some restrictions for doing so.Checklist