summaryrefslogtreecommitdiff
path: root/open_issues/gnumach_memory_management.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues/gnumach_memory_management.mdwn')
-rw-r--r--open_issues/gnumach_memory_management.mdwn33
1 files changed, 33 insertions, 0 deletions
diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn
index fb3d6895..9a4418c1 100644
--- a/open_issues/gnumach_memory_management.mdwn
+++ b/open_issues/gnumach_memory_management.mdwn
@@ -1777,3 +1777,36 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task.
<braunr> an idea for when there's time
<braunr> eh
<antrik> hehe :-)
+
+
+# IRC, freenode, #hurd, 2011-10-13
+
+ <braunr> mcsim: what's the current state of your gnumach branch ?
+ <mcsim> I've merged it with master in September
+ <braunr> yes i've seen that, but does it build and run fine ?
+ <mcsim> I've tested it on gnumach from debian repository, but for building
+ I had to make additional change in device/ramdisk.c, as I mentioned.
+ <braunr> mcsim: why ?
+ <mcsim> And it runs fine for me.
+ <braunr> mcsim: why did you need to make other changes ?
+ <mcsim> because there is a patch which comes with from-debian-repository
+ kernel and it addes some code, where I have to make changes. Earlier
+ kernel_map was a pointer to structure, but I change that and now
+ kernel_map is structure. So handling to it should be by taking the
+ address (&kernel_map)
+ <braunr> why did you do that ?
+ <braunr> or put it another way: what made you do that type change on
+ kernel_map ?
+ <mcsim> Earlier memory for kernel_map was allocating with zalloc. But now
+ salloc can't allocate memory before it's initialisation
+ <braunr> that's not a good reason
+ <braunr> a simple workaround for your problem is this :
+ <braunr> static struct vm_map kernel_map_store;
+ <braunr> vm_map_t kernel_map = &kernel_map_store;
+ <mcsim> braunr: Ok. I'll correct this.
+
+
+# IRC, freenode, #hurd, 2011-11-01
+
+ <braunr> etenil: but mcsim's work is, for one, useful because the allocator
+ code is much clearer, adds some debugging support, and is smp-ready