uefi-rs
uefi-rs copied to clipboard
Request for EFI_SHELL_INTERFACE
Name: EFI_SHELL_INTERFACE
GUID: 47C7B223-C42A-11D2-8E57-00A0C969723B
Docs: https://bsdio.com/edk2/docs/master/struct_e_f_i___s_h_e_l_l___i_n_t_e_r_f_a_c_e.html
Reason: Using it to parse boot arguments
Hi! If you (or anyone else) is interested in adding this protocol to uefi-rs
, contributions are welcome :) I'd recommend checking out the contributing instructions section on how to add new protocols.
I'm interested in taking this on if nobody else is.
Thanks, please feel free :)
For our future reference, here's the current latest UEFI Shell Spec: https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf
@nicholasbishop
This protocol relies on linked lists for the functions dealing with, surprisingly, lists of files. The structure defined by UEFI looks like this:
#[repr(C)]
pub struct ShellFileInfo {
link: ListEntry,
status: Status,
full_name: *const CStr16,
file_name: *const CStr16,
shell_file_handle: Handle,
info: *mut FileInfo
}
#[repr(C)]
pub struct ListEntry {
flink: *mut ListEntry,
blink: *mut ListEntry,
}
Do you have any advice or know of any good resources for abstracting over this in a safe and at least somewhat Rust-y way, without alloc
? Most of what I've seen makes use of arena allocation with Vec
or using Box
for the links, but I don't think I should make alloc
a requirement for this protocol.
I think you can represent this with a struct that implements Iterator
. Internally the struct will have a pointer to the current entry that gets advanced in each call to next
. Then you don't need to alloc anything on the heap since you're only dealing with one element at a time, and if the end-user does want to alloc into a vec, they can call the standard .collect::<Vec<_>>()
.
I was looking into implementing EFI_SHELL_INTERFACE
since it's what my target device exposes for parameters. However, I noticed that it's specific to EDK2 (not in the UEFI Shell spec), which refers to it as shell 1.0 or EDK Shell (I guess that's the original EFI/EDK?). It seems the official "replacement" is the ShellParams
protocol (implemented in #772).
So, would opening a PR for this even make sense?
A PR for that would be welcome, yes :)
Note though that in general you don't need any shell protocol to access the parameters passed to an image -- you can use the LoadedImage
protocol. The load_options_as_cstr16
method can be used if the parameters are a normal null-terminated string. The load_options_as_bytes
method can be used for raw access. The various shell parameter protocols provide a somewhat more convenient interface, automatically splitting arguments out of the string and handling quoting and such, but for simple arguments you may not need all that.