diff options
author | Samuel Thibault <samuel.thibault@ens-lyon.org> | 2011-11-05 14:50:57 +0100 |
---|---|---|
committer | Samuel Thibault <samuel.thibault@ens-lyon.org> | 2011-11-05 14:50:57 +0100 |
commit | 3b6491bff3a456868ea8c2ccfbd3328d272e8543 (patch) | |
tree | 9709b6e2b20e3cba3e88be29b37a8c8796bc8cf7 /open_issues/gnumach_memory_management.mdwn | |
parent | ad0f2aa843232649166e0252e28b96c1736c5082 (diff) | |
parent | e640b97228bd1214a4dc37ac9d79a704acd40c0c (diff) |
Merge branch 'master' of flubber:~hurd-web/hurd-web
Diffstat (limited to 'open_issues/gnumach_memory_management.mdwn')
-rw-r--r-- | open_issues/gnumach_memory_management.mdwn | 33 |
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 |