Thanks for the PR!

The change to add a MemoryType parameter to exit_boot_services seems reasonable, I'm happy to accept that.

I'm a little less sure about the lifetime fix. While I think what you have probably works fine for exit_boot_services, where the lifetime is static, it's possible to get the memory map prior to that via BootServices::memory_map, and I'm not 100% sure your code is correct for that situation. The tricky thing here is that MemoryMap contains a mut reference, which places stricter bounds on the lifetime of &self methods. See this example on the playground. I'm not sure that the unsafe isn't just laundering lifetimes in a UB way.

It seems like there's a conflict here between having the mutable sort method on MemoryMap, and the desire to have MemoryMapIter have a lifetime matching the MemoryMap 'buf lifetime, and if possible I'd like to solve it without unsafe. A couple ideas:

1. We could rename MemoryMap to MemoryMapMut, and a second MemoryMap type that contains non-mut reference to the data. Then add a conversion method to MemoryMapMut that consumes self and returns a MemoryMap.
2. We could change MemoryMap::entries to consume self, which would allow MemoryMapIter<'buf> to be returned. The downside is that you wouldn't be able to call MemoryMap::key after that, and you'd only get one iteration unless we modified MemoryMapIter to have a reset method or something like that.

There may be other options, open to ideas here :)

@nicholasbishop

I'm a little less sure about the lifetime fix. While I think what you have probably works fine for exit_boot_services, where the lifetime is static, it's possible to get the memory map prior to that via BootServices::memory_map, and I'm not 100% sure your code is correct for that situation.

The MemoryMapIter get the buffer's location from MemoryMap and keep it's lifetime. So I think that it's equivalent between my code and the current MemoryMapIter implementation in ther master branch. (Use *const u8 + PhantomData<'buf> instead of &'buf mut [u8]) The point is that the 'buf tracking the buffer's lifetime but not MemoryMap's.

I'm not sure that the unsafe isn't just laundering lifetimes in a UB way.

But I'm not sure if there are some of unsafe and UB that you mentioned. Could you tell me about it? In MemoryMap::entries() and MemoryMapIter, only MemoryMapIter::next() use a unsafe block.

Here's a concrete example showing UB:

fn test_mem_map(bt: &BootServices) {
    let sizes = bt.memory_map_size();
    let mut buffer = vec![0; sizes.map_size * sizes.entry_size];
    let mut memory_map = bt.memory_map(&mut buffer).unwrap();

    let mut entries = memory_map.entries();
    info!("first entry: {:?}", entries.next());
    // UB! The data being iterated over is modified while we have a supposedly
    // immutable reference to the data.
    memory_map.sort();
    info!("next entry: {:?}", entries.next());
}

In the main branch this won't compile; the call to memory_map.sort() fails because memory_map is already borrowed as immutable. But it does compile on top of this PR, because the use of a raw pointer prevents this lifetime analysis.