summaryrefslogtreecommitdiff
path: root/open_issues/gnumach_vm_map_entry_forward_merging.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues/gnumach_vm_map_entry_forward_merging.mdwn')
-rw-r--r--open_issues/gnumach_vm_map_entry_forward_merging.mdwn11
1 files changed, 11 insertions, 0 deletions
diff --git a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn
index b2b20c5b..f1c8bd6e 100644
--- a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn
+++ b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn
@@ -171,6 +171,17 @@ License|/fdl]]."]]"""]]
entries)
+# IRC, freenode, #hurd, 2011-07-21
+
+ <braunr> tschwinge: you may remove the forward map entry merging issue :/
+ <pinotree> what did you discover?
+ <braunr> tschwinge: it's actually much more complicated than i thought, and
+ needs major changes in the vm, and about the way anonymous memory is
+ handled
+ <braunr> from what i could see, part of the problem still exists in freebsd
+ <braunr> for the same reasons (shadow objects being one of them)
+
+
# Procedure
* Analyze.