summaryrefslogtreecommitdiff
path: root/microkernel/mach/gnumach
diff options
context:
space:
mode:
authorThomas Schwinge <thomas@schwinge.name>2011-02-16 10:11:16 +0100
committerThomas Schwinge <thomas@schwinge.name>2011-02-16 10:12:04 +0100
commitb91f1d19f234c6da2ad4795db625030be855c992 (patch)
treeb4b9293b4bbc338dd7aaf59f01cfe1a0d26e4b22 /microkernel/mach/gnumach
parent8feb7eec8c1abfb833fff5ac54ac3cea67d7b0a7 (diff)
microkernel/mach/gnumach/memory_management: New.
Diffstat (limited to 'microkernel/mach/gnumach')
-rw-r--r--microkernel/mach/gnumach/memory_management.mdwn36
1 files changed, 36 insertions, 0 deletions
diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn
new file mode 100644
index 00000000..49a082e9
--- /dev/null
+++ b/microkernel/mach/gnumach/memory_management.mdwn
@@ -0,0 +1,36 @@
+[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+IRC, freenode, #hurd, 2011-02-15
+
+ <braunr> etenil: originally, mach had its own virtual space (the kernel
+ space)
+ <braunr> etenil: in order to use linux 2.0 drivers, it now directly maps
+ physical memory, as linux does
+ <braunr> etenil: but there is nothing similar to kmap() or vmalloc() in
+ mach, so the kernel is limited to its 1 GiB
+ <braunr> (3 GiB userspace / 1 GiB kernelspace)
+ <braunr> that's the short version, there is a vmalloc() in mach, but this
+ trick made it behave almost like a kmalloc()
+ <antrik> braunr: the direct mapping is *only* for the benefit of Linux
+ drivers?...
+ <braunr> also, the configuration of segments limits the kernel space
+ <braunr> antrik: i'm not sure, as i said, this is the short version
+ <braunr> antrik: but there is a paper which describes the integration of
+ those drivers in mach
+ <etenil> you mean the linux 2.0 drivers?
+ <antrik> braunr: I read it once, but I don't remember anything about the
+ physical mapping in there...
+ <antrik> etenil: well, originally it was 1.3, but essentially that's the
+ same...
+ <braunr> i don't see any other reason why there would be a direct mapping
+ <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)