Request for EFI_SHELL_INTERFACE

[stevefan1999-personal]

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

[GabrielMajeri]

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.

[timrobertsdev]

I'm interested in taking this on if nobody else is.

[nicholasbishop]

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

[timrobertsdev]

@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.

[nicholasbishop]

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<_>>().

[fnetz]

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?

[nicholasbishop]

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.