OpenProtocolAttributes missing EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL

[ori-sky]

The OpenProtocolAttributes enum is currently missing a representation of the EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL value defined by UEFI. Without this, there doesn't seem to be a way to directly open a protocol from a specified handle non-exclusively. Some example code:

let boot_services = system_table.boot_services();

let search = SearchType::from_proto::<GraphicsOutput>();
let handle_buffer = boot_services.locate_handle_buffer(search)?;

for handle in handle_buffer.handles() {
    let params = OpenProtocolParams {
        handle: *handle,
        agent: image,
        controller: None
    };
    let attribs = unsafe { core::mem::transmute(1) };
    let gop = unsafe {
        boot_services.open_protocol::<GraphicsOutput>(params, attribs)?
    };

    let modeinfo = gop.current_mode_info();
    let (width, height) = modeinfo.resolution();
    uefi_services::println!("Graphics mode: {}x{}", width, height);
}

When attempting to open the GraphicsOutput protocol exclusively here, an error seems to be encountered, presumably either upon opening the protocol or somewhere in uefi_services::println!, so non-exclusivity seems to be required here. However, the code succeeds when performing the unsafe transmute from 1 (the value that EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL is defined to be).

[nicholasbishop]

You can use OpenProtocolAttributes::GetProtocol for that. See https://github.com/rust-osdev/uefi-rs/blob/main/uefi-test-runner/src/proto/console/gop.rs#L5 for an example of this in action.

[ori-sky]

It looks like GetProtocol will work in this circumstance so this ticket probably no longer affects me, although more generally GET_PROTOCOL does have the caveat that any notification events created to be signaled upon a protocol being reinstalled will not be notified in the case of the protocol having been opened via GET_PROTOCOL -- only if it has been opened via BY_HANDLE_PROTOCOL, if I'm understanding the UEFI spec correctly.