summaryrefslogtreecommitdiff
path: root/microkernel/mach/gnumach/memory_management.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'microkernel/mach/gnumach/memory_management.mdwn')
-rw-r--r--microkernel/mach/gnumach/memory_management.mdwn14
1 files changed, 14 insertions, 0 deletions
diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn
index 49a082e9..17dbe46f 100644
--- a/microkernel/mach/gnumach/memory_management.mdwn
+++ b/microkernel/mach/gnumach/memory_management.mdwn
@@ -34,3 +34,17 @@ IRC, freenode, #hurd, 2011-02-15
<braunr> except for performance (because you can use larger - even very
lage - pages without resetting the mmu often thanks to global pages, but
that didn't exist at the time)
+
+IRC, freenode, #hurd, 2011-02-15
+
+ <antrik> however, the kernel won't work in 64 bit mode without some changes
+ to physical memory management
+ <braunr> and mmu management
+ <braunr> (but maybe that's what you meant by physical memory)
+
+IRC, freenode, #hurd, 2011-02-16
+
+ <braunr> antrik: youpi added it for xen, yes
+ <braunr> antrik: but you're right, since mach uses a direct mapped kernel
+ space, the true problem is the lack of linux-like highmem support
+ <braunr> which isn't required if the kernel space is really virtual