Abstract away boot modules and memory maps#149
Conversation
src/kernel/arch/x86/arch.zig
Outdated
| // Reserve the unavailable sections from the multiboot memory map | ||
| for (mem_map) |entry| { | ||
| if (entry.@"type" != multiboot.MULTIBOOT_MEMORY_AVAILABLE) { | ||
| const end: usize = if (entry.addr + entry.len > std.math.maxInt(usize)) std.math.maxInt(usize) else @intCast(usize, entry.addr + entry.len); |
There was a problem hiding this comment.
This if can cause a integer overflow, would be better: entry.addr > std.math.maxInt(usize) - entry.len. Also, what happens if the end is too long as this would lead to the OS using unavailable memory as it couldn't fit it in a uzise. Maybe best to error here.
There was a problem hiding this comment.
Nice idea on the if statement. Regarding the other point, what do you mean by the end being too long?
There was a problem hiding this comment.
if entry.addr + entry.len > std.math.maxInt(usize) this is true, then you just use std.math.maxInt(usize) so there there will be memory that won't be mapped out.
There was a problem hiding this comment.
I don't quite see how using maxInt(usize) is a problem. Since x86 is 32-bit it can't address the memory beyond maxInt(usize) anyway so ignoring whatever comes after that in memory map entry should be fine.
There was a problem hiding this comment.
Ah yes, good point, maybe add a comment :)
SamTebbs33
force-pushed
the
feature/arch-boot-payload
branch
from
042bcca to
e8838ff
Compare
Noice, now I can do some more work on the aarch64 port :D |
SamTebbs33
force-pushed
the
feature/arch-boot-payload
branch
from
0d6213a to
554b970
Compare
2 participants
Closes #147
This patch removes the dependence on multiboot since not all architectures will use a multiboot-compliant bootloader (the Raspberry Pi for example). This meant allowing the architecture to decide what regions of memory are reserved and which are available for use by the VMM, which had the consequence of making the VMM's allocation of reserved memory cleaner.