Setting Aside Space for Memory Map List

[dengeltheyounger]

I don't really know if this is a stupid question, however, I've been looking at page frame allocation. There are two different parts to it that I see. The first is getting a memory map representing the usable memory (which is outlined here: https://wiki.osdev.org/Detecting_Memory_(x86)). The second is actually writing a page frame allocator. The second part I've already asked about. The first part I'm not really interested in since there's so much written about it already.

The thing that I am wondering about is how to go about setting aside memory for the memory map list. The wiki page seemed to presuppose that you already have an array of list entries pre-allocated, but it doesn't seem like you can know that until you actually get the number of available entries. I would go through and do the int 0x15 BIOS calls first in order to get the number of entries, and then allocate the number of entries based on that. However, that would pre-suppose having a page frame allocator, since anything I allocate without dynamic memory allocation would go out of scope as soon as I leave the function (unless I'm missing something really obvious).

Another option would be to pre-allocate an array so big that it would cover any number of potential number of entries that could be returned. Given that the number of list entries is stored in %bp, the total number of entries cannot exceed 65535. However, allocating that many list entries would mean dedicating 1,572,840 bytes just for the memory map.

How did you go about setting aside space for the memory map entries, assuming my question isn't a non-starter.

[iansjack]

Just create the array, using pages that you know are free, and mark those pages as used when you initialize the bitmap.

[linguofreak]

I don't really know if this is a stupid question, however, I've been looking at page frame allocation. There are two different parts to it that I see. The first is getting a memory map representing the usable memory (which is outlined here: https://wiki.osdev.org/Detecting_Memory_(x86)). The second is actually writing a page frame allocator. The second part I've already asked about. The first part I'm not really interested in since there's so much written about it already.

The thing that I am wondering about is how to go about setting aside memory for the memory map list. The wiki page seemed to presuppose that you already have an array of list entries pre-allocated, but it doesn't seem like you can know that until you actually get the number of available entries. I would go through and do the int 0x15 BIOS calls first in order to get the number of entries, and then allocate the number of entries based on that. However, that would pre-suppose having a page frame allocator, since anything I allocate without dynamic memory allocation would go out of scope as soon as I leave the function (unless I'm missing something really obvious).

Before you've read the memory map, you're likely executing in physical memory below the 1 MB mark. The number of kB available in the < 1 MB range is given by the value stored at address 0x0413 in the BIOS Data Area, and RAM is guaranteed to be contiguous from 0 on up to that number of kilobytes. So your code and statically allocated data will occupy some portion of the < 1 MB region that is known at compile time, and then you can set up a heap for dynamically allocation in the rest of the < 1 MB region.

[dengeltheyounger]

Before you've read the memory map, you're likely executing in physical memory below the 1 MB mark. The number of kB available in the < 1 MB range is given by the value stored at address 0x0413 in the BIOS Data Area, and RAM is guaranteed to be contiguous from 0 on up to that number of kilobytes. So your code and statically allocated data will occupy some portion of the < 1 MB region that is known at compile time, and then you can set up a heap for dynamically allocation in the rest of the < 1 MB region.

That's a really good idea. I'm definitely going to look into that.

[dengeltheyounger]

So, I wanted to spend some time discussing a certain nuance that I didn't realize until yesterday. I think this might help other people who are just starting out and want to work out this memory map business:

The BIOS calls that are described on the wiki don't actually work in protected mode (there's like one BIOS call designed for protected mode, but from what I've read, it doesn't give a memory map. It just gives the amount of memory available). For that reason, the process of getting the memory map should be done at the boot loader stage. If you are using GRUB (or QEMU, which is what I use), a lot of stuff is already done for you. The memory map has already been set up. VGA has also been set up. For that reason, it's probably best just to let the bootloader get the memory map for you, and then you can focus your time and effort on understanding the API so that you can get the memory map which has been built: https://wiki.osdev.org/Detecting_Memory ... p_Via_GRUB

I don't know if this memory map is naturally built by QEMU, or if you have to pass the multiboot_info_t * in order to tell QEMU's bootloader to build the memory map. However, this is probably the clearest way to do it unless you are rolling your own bootloader. Alternatively, you can go into real mode to make the BIOS call and then go back into protected mode, but that sounds like a very bad idea.

I hope this helps newbies like me.