summaryrefslogtreecommitdiff
path: root/open_issues/gnumach_memory_management.mdwn
diff options
context:
space:
mode:
authorThomas Schwinge <thomas@schwinge.name>2011-11-04 19:22:41 +0100
committerThomas Schwinge <thomas@schwinge.name>2011-11-04 19:22:41 +0100
commite8ab9711504055c81d164aa35e0629c2c81f1082 (patch)
tree68d4b846188ad3a90cf7f732c849f85c5b3e8640 /open_issues/gnumach_memory_management.mdwn
parent5d44547d701fe96aef425c6e3f719df9a34581e8 (diff)
parentbe49aa7ddec52e121d562e14d4d93fd301b05fbb (diff)
Merge remote-tracking branch 'fp/master'
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