However, if you write a kernel and get the raw memory map from your bootloader, one has to parse the memory map from this raw memory.

Could the kernel take ownership of this memory and use the existingstruct MemoryMap instead of a reference type?

Don't think so (from a library standpoint) . Most abstraction for boot loader information provide you only&[u8] access, including but not limited to Limine (w/ Limine boot protocol) and multiboot2

Only&[u8], or&mut [u8] too? (Wondering aboutMemoryMapRefMut)

Only&[u8], or&mut [u8] too? (Wondering aboutMemoryMapRefMut)

Yes, there were actually requests to be able to modify structures, such as the memory map. For example in themultiboot2 repository. Limine's boot protocol, or to be more specific, the limine crate, also provides you witha slice/a buffer - this is however not mutable yet - but it could be extended in the future.

Note that we need mutable access so that one can call the.sort() function.

I'm not sure if the proposed solution is 100% perfect - but it enables all use cases users will have - giving developers maximum freedom.

What do you think about this? What about the other questions mentioned above?

Makes sense. I haven't looked through the details of the PR yet (doing so now), I just wanted to make sure I understood how it would be used at a high level first.

I didn't manage to make the traits directly dependent on Index and IndexMut - I gave up after many compiler warnings.

This seems to work:

pubtraitMemoryMap:Debug +Index<usize,Output =MemoryDescriptor>{

(At least, it compiles, I didn't test it thoroughly.)

There is still code repetition. Especially for the implementations of Index and IndexMut which I have to provide 3 times. Any idea for improvement? Just use a macro?

I think it's OK as-is, there is some code repetition but it's not too bad.

I didn't manage to make the traits directly dependent on Index and IndexMut - I gave up after many compiler warnings.

This seems to work:

pubtraitMemoryMap:Debug +Index<usize,Output =MemoryDescriptor>{

(At least, it compiles, I didn't test it thoroughly.)

I'll do/try this in a follow-up (#1240 ).

So,@nicholasbishop , what do you think? I know, I did a major overhaul of the MemoryType API in the past weeks. But I think it is worth it and that we now reached it a point where it is mature and sustainable. However, I'm also biased 😁 What do you think?

I know, I did a major overhaul of the MemoryType API in the past weeks. But I think it is worth it and that we now reached it a point where it is mature and sustainable. However, I'm also biased 😁 What do you think?

I think it's a reasonable change, looks good to me. FWIW I don't think there's anything wrong with making more API changes after a recent API change if we realize that more improvements are needed. For me the important thing is that it's easy for users of the API to update their code when updating to a new version of uefi-rs. And certainly for these changes I don't think there's any problem there, it's very straightforward to changeMemoryMap toMemoryMapOwned, and then potentially use the other new traits as needed.