can't get size of memory_map when it's a failed Result

[balenamiaa]

In case the status is Status::BUFFER_TOO_SMALL, map_size should be available. Perhaps through the Error's optional ErrData? Also, memory_map_size is internal, so, the only way seems to be directly using the raw methods in the boot table.

let memory_map = loop {
    let mut memory_map = uefi::boot::memory_map(MemoryType::LOADER_DATA);
    log::info!("memory_map: {:?}", memory_map);

    match memory_map {
        Ok(e) => break e,
        Err(e) => {
            if e.status() == Status::BUFFER_TOO_SMALL {
                log::info!("Buffer too small. Allocating more memory...");
                let memory_map_size = ???;
                memory_map = uefi::boot::allocate_pool(MemoryType::LOADER_DATA, ???);
            }
        }
    }
};

[phip1611]

Hey! Did you actually experience situations where uefi::boot::memory_map(MemoryType::LOADER_DATA) returned Status::BUFFER_TOO_SMALL or is this just defensive programming?

Actually, uefi::boot::memory_map doesn't expect users to handle the Status::BUFFER_TOO_SMALL use-case due to advanced internal logic. I'm updating the doc

[balenamiaa]

Hi! Yes, I have. Inside of a ExitBootServices hook that's called by winload.efi. What is meant by advanced internal logic? Regardless, thanks for the documentation update!

[phip1611]

Hey,

as you can see in #1540, you are not supposed to handle Status::BUFFER_TOO_SMALL when you use uefi::boot::memory_map().

The reason for that is that memory_map() internally already contains logic to have a large enough buffer. This complexity is taken away from users.

Does that help?

[balenamiaa]

Hello! I understand that uefi::boot::memory_map() internally handles buffer sizing, but in my particular case, I needed more control.

I do not call/control uefi::boot::memory_map(); winload.efi calls ExitBootServices with the assumption the memory map is not stale, and it will be if allocations happen in what is supposed to be "ExitBootServices" (the hook) before calling the real function, While OslFwpKernelSetupPhase1 itself handles stale memory maps, taking extra precautions seemed safer then.

Anyway, as this is something rare, I don't think there's a need to complicate the API - as long as the raw tables continue to be exposed.

Thanks for your time and input on this!