Expose `MemoryMapIter` in API

[tsoutsman]

Hi, I'm creating a frame allocator for my UEFI bootloader and have encountered some problems with memory_map. Since memory_map returns a generic rather than a concrete type, my frame allocator needs generics:

pub struct FrameAllocator<'a, I>
where
    I: ExactSizeIterator<Item = &'a MemoryDescriptor> + Clone,
{
    memory_map: I,
    // other fields
}

This means that anything using my frame allocator also needs generics.

Using generics isn't great, but obviously isn't the end of the world. There may be better reasons for the output type to remain generic, I'm just showing my specific use case.

[phip1611]

Hi @tsoutsman,
I think that memory_map could indeed return a specific type as the generic return type only adds complexity that is not needed. The following patch works:

diff --git a/uefi/src/table/boot.rs b/uefi/src/table/boot.rs
index b30cd64..8746dcc 100644
--- a/uefi/src/table/boot.rs
+++ b/uefi/src/table/boot.rs
@@ -402,7 +402,7 @@ impl BootServices {
         buffer: &'buf mut [u8],
     ) -> Result<(
         MemoryMapKey,
-        impl ExactSizeIterator<Item = &'buf MemoryDescriptor> + Clone,
+        MemoryMapIter<'buf>,
     )> {
         let mut map_size = buffer.len();
         MemoryDescriptor::assert_aligned(buffer);
@@ -1799,7 +1799,7 @@ pub struct MemoryMapSize {
 
 /// An iterator of memory descriptors
 #[derive(Debug, Clone)]
-struct MemoryMapIter<'buf> {
+pub struct MemoryMapIter<'buf> {
     buffer: &'buf [u8],
     entry_size: usize,
     index: usize,

@nicholasbishop what do you think? I'm in favor of a simplification for that interface.

PS: @tsoutsman
Temporarily, I think, you can type the frame allocator like that:

pub struct FrameAllocator<'a>
{
    memory_map: Box<ExactSizeIterator<Item = &'a MemoryDescriptor>>,
}

[liferooter]

pub struct FrameAllocator<'a>
{
    memory_map: Box<ExactSizeIterator<Item = &'a MemoryDescriptor>>,
}

Using Box<T> is impossible without an allocator. So using it in allocator implementation is not good idea at all.

[phip1611]

Oh yeah, sorry. :D
What about using &dyn?

[liferooter]

This could work, yes

[liferooter]

Oh yeah, sorry. :D What about using &dyn?

This still causes a lot of hard-to-solve problems with generics and lifetimes