From be49aa7ddec52e121d562e14d4d93fd301b05fbb Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 4 Nov 2011 19:19:35 +0100 Subject: IRC. --- open_issues/gnumach_memory_management.mdwn | 33 ++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) (limited to 'open_issues/gnumach_memory_management.mdwn') 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. an idea for when there's time eh hehe :-) + + +# IRC, freenode, #hurd, 2011-10-13 + + mcsim: what's the current state of your gnumach branch ? + I've merged it with master in September + yes i've seen that, but does it build and run fine ? + 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. + mcsim: why ? + And it runs fine for me. + mcsim: why did you need to make other changes ? + 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) + why did you do that ? + or put it another way: what made you do that type change on + kernel_map ? + Earlier memory for kernel_map was allocating with zalloc. But now + salloc can't allocate memory before it's initialisation + that's not a good reason + a simple workaround for your problem is this : + static struct vm_map kernel_map_store; + vm_map_t kernel_map = &kernel_map_store; + braunr: Ok. I'll correct this. + + +# IRC, freenode, #hurd, 2011-11-01 + + etenil: but mcsim's work is, for one, useful because the allocator + code is much clearer, adds some debugging support, and is smp-ready -- cgit v1.2.3