From 95878586ec7611791f4001a4ee17abf943fae3c1 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/g3Ccalpj0NhN566pHbUl6i9QF0QEkrhlfPM-#b1c14" Date: Mon, 16 Feb 2015 20:08:03 +0100 Subject: rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn --- .../placement_of_virtual_memory_regions.mdwn | 103 --------------------- 1 file changed, 103 deletions(-) delete mode 100644 open_issues/placement_of_virtual_memory_regions.mdwn (limited to 'open_issues/placement_of_virtual_memory_regions.mdwn') diff --git a/open_issues/placement_of_virtual_memory_regions.mdwn b/open_issues/placement_of_virtual_memory_regions.mdwn deleted file mode 100644 index 39478f20..00000000 --- a/open_issues/placement_of_virtual_memory_regions.mdwn +++ /dev/null @@ -1,103 +0,0 @@ -[[!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 :/ -- cgit v1.2.3