Is the memory map static?

[mrjbom]

Hi.
I use the memory map obtained from GRUB.
I write the free memory areas to my table. I'm wondering if these addresses and the sizes of these areas can change as the computer works. Do I need to update my previously obtained memory area data?

I think not, but it's better to know for sure.

[nexos]

No, because that would be very hard to do right and to know when to re-obtain the map. As far as my knowledge goes, no.

[mrjbom]

No, because that would be very hard to do right and to know when to re-obtain the map. As far as my knowledge goes, no.

What should I do in this case? How do I track its changes? When should I update my data?

[iansjack]

Not sure what you mean. Free memory only changes as you allocate pages; it's the reponsibility of the OS to keep track of which pages it has allocated (and therefore which are still free).

[mrjbom]

Not sure what you mean. Free memory only changes as you allocate pages; it's the reponsibility of the OS to keep track of which pages it has allocated (and therefore which are still free).

I mean, can the memory map to change myself.
Can the data about RAM partitions received from grub change by itself? Or do they not change?

[iansjack]

Why would they change?

[eekee]

There is such a thing as hot-pluggable RAM, but I think very few of us here have to worry about that particular craziness. Ditto hot-pluggable PCI. We don't have supercomputers.

[mrjbom]

Okay, thanks, I thought so. I just wanted to clarify.
Thanks.

[Octocontrabass]

Hot-pluggable RAM and CPUs are very popular in enterprise virtual machines, where there's a pretty high demand for being able to scale resources up or down while the OS and applications are running.

PCI hotplug is working its way into consumer electronics in the form of Thunderbolt and SD Express.

[eekee]

Ah, thanks Octocontrabass. Well, I'm sure beginner OS devs are not expected to support hot-pluggable RAM. Interesting that Thunderbolt is so closely related to PCIe; it might be easy to support. I'm not so sure about the other parts of it, though.

[ITchimp]

I am looking for the definition fille (.h) for struct mboot or struct mboot_header...do you know where to get it?

[kzinti]

https://github.com/kiznit/rainbow-os/tr ... /multiboot

[Octocontrabass]

They can also be found in the Multiboot and Multiboot2 specifications.

The Multiboot specifications don't use the names "mboot" or "mboot_header" so that probably came from someone else's implementation of the header. (You can write your own header based on the spec instead of using the one in the spec.)

[bellezzasolo]

Not in GRUB, but it's worth noting that something like this sort of is possible in UEFI.
It doesn't happen automagically, though. Calls to Boot Services can result in changes to the memory map.

When you call GetMemoryMap, UEFI gives you a mapKey.
When you call ExitBootServices, you need to pass that same mapKey, and an error will be returned if it has changed in the interim!

[bzt]

Not in GRUB, but it's worth noting that something like this sort of is possible in UEFI.
It doesn't happen automagically, though. Calls to Boot Services can result in changes to the memory map.

When you call GetMemoryMap, UEFI gives you a mapKey.
When you call ExitBootServices, you need to pass that same mapKey, and an error will be returned if it has changed in the interim!

EFI applications and drivers can allocate and free memory which changes the map. Calling ExitBootServices guarantees that all further memory allocation calls will result in an error code. Therefore RunTime Services must operate on static memory (allocated at initialization stage), and BootTime Services are not accessible at all after ExitBootServices call.

For BIOS, this can't happen as BIOS doesn't have memory allocation functions, so BIOS code can't allocate memory to change the map. E820 will remain static (this is what GRUB returns for you).

Cheers,
bzt