[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[!tag open_issue_gnumach]] # IRC, freenode, #hurd, 2011-07-13 does anyone know if posix (or mach) has requirements or a policy about the placement of allocations of virtual space ? a policy such as bottom-up ? or "find lowest vailable space" ? braunr, you mean for vm_allocate ? You may want to check mmap() but I can't remember ever coming across such a thing (except maybe wrt. alignment) i was wondering how e.g. libraries are linked near the stack (possibly at slightly random addresses) does the linker walk the address space entries top-down ? jkoenig: i didn't see anything either in the mach interface, but i may have missed something jkoenig: most systems i've been studying mark the vm regions for the heap and the stack but for mach, the stack is just allocated virtual memory at the top of the space so the "placement policy" is either completely outside the kernel, or relies on its interface braunr, actually I'm surprised Mach would even dictate where the (one?) stack should be, I would have expected it to be the job of whatever creates a thread to make this kind of choice jkoenig: threads have their own stacks, under the responsibility of the user trhead implementation but a program usually needs a stack even before it runs i had to set one to bootstrap modules in v0.1 but i wonder if it's just for bootstrapping (and then propagated by fork()) or part of the interface but this doesn't matter much actually, the allocation mechanism i have in mind can actually support multiple policies I would guess the former (just for bootstrapping), since a new task has no thread, and a new thread has no state. (but I'm no expert) i think so i'll have a look at the exec server jkoenig: did the previous implementation of procfs show task maps ? braunr, I don't think so, I would probably have felt compelled to include them in the new one if it did :-) hmmm we definitely need that is there a compelling use case you think about in particular? yes i failed to understand how gnumach behaved wrt ipc right spaces [[rework_gnumach_ipc_spaces]] and when i did, i found out my work was impossible to integrate "ipc right spaces" ? each task have an ipc space, which contains righs rights the ipc translation layer converts space/name and space/port tuples to rights i wanted to replace the splay tree with a radix tree but didn't get how the ipc table made the splay tree almost unused i don't want to make this kind of mistake again, so i'd like a clear and detailed view of the vm spaces (it's only compelling for myself, all right) but we have vminfo rbraun@nordrassil:~$ vminfo $$ | wc -l 1046 oh my in comparison, a firefox instance has less than 500 on linux you mean there's some kind of port name table (or functional equivalent) which actually resides in the task's memory? (and that's what shows up at the beginning of the address space with prot=0?) jkoenig: sorry for being confusing, it's not that at all (btw feel free to tell me to just go read the source or whatever) jkoenig: don't worry braunr, no problem jkoenig: i just compared a previous attempt to improve gnumach which failed because i didn't have enough insight of the inner workings of the kernel jkoenig: i really want to miss as little as possible on the vm part, so having detailed information about what actually happens on running hurd systems is something i need # IRC, freenode, #hurd, 2011-07-24 oh btw, i noticed there are many mappings below the program text most notably, the stack except for special applications like wine, could this break anything ? i also wonder how libraries are mapped, because there is nothing to perform top-down allocations which means if the region below the program text is exhausted, libraries could be mapped right after the heap it shouldn't break anything except things like wine & libgc, yes which could make malloc() fail :/