rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn

1 files changed, 0 insertions, 103 deletions

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
-
-    <braunr> does anyone know if posix (or mach) has requirements or a policy
-      about the placement of allocations of virtual space ?
-    <braunr> a policy such as bottom-up ?
-    <braunr> or "find lowest vailable space" ?
-    <jkoenig> 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)
-    <braunr> i was wondering how e.g. libraries are linked near the stack
-      (possibly at slightly random addresses)
-    <braunr> does the linker walk the address space entries top-down ?
-    <braunr> jkoenig: i didn't see anything either in the mach interface, but i
-      may have missed something
-    <braunr> jkoenig: most systems i've been studying mark the vm regions for
-      the heap and the stack
-    <braunr> but for mach, the stack is just allocated virtual memory at the
-      top of the space
-    <braunr> so the "placement policy" is either completely outside the kernel,
-      or relies on its interface
-    <jkoenig> 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
-    <braunr> jkoenig: threads have their own stacks, under the responsibility
-      of the user trhead implementation
-    <braunr> but a program usually needs a stack even before it runs
-    <braunr> i had to set one to bootstrap modules in v0.1
-    <braunr> but i wonder if it's just for bootstrapping (and then propagated
-      by fork()) or part of the interface
-    <braunr> but this doesn't matter much actually, the allocation mechanism i
-      have in mind can actually support multiple policies
-    <jkoenig> 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)
-    <braunr> i think so
-    <braunr> i'll have a look at the exec server
-    <braunr> jkoenig: did the previous implementation of procfs show task maps
-      ?
-    <jkoenig> braunr, I don't think so, I would probably have felt compelled to
-      include them in the new one if it did :-)
-    <braunr> hmmm
-    <braunr> we definitely need that
-    <jkoenig> is there a compelling use case you think about in particular?
-    <braunr> yes
-    <braunr> i failed to understand how gnumach behaved wrt ipc right spaces
-
-[[rework_gnumach_ipc_spaces]]
-
-    <braunr> and when i did, i found out my work was impossible to integrate
-    <jkoenig> "ipc right spaces" ?
-    <braunr> each task have an ipc space, which contains righs
-    <braunr> rights
-    <braunr> the ipc translation layer converts space/name and space/port
-      tuples to rights
-    <braunr> 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
-    <braunr> i don't want to make this kind of mistake again, so i'd like a
-      clear and detailed view of the vm spaces
-    <braunr> (it's only compelling for myself, all right)
-    <braunr> but
-    <braunr> we have vminfo
-    <braunr> rbraun@nordrassil:~$ vminfo $$ | wc -l
-    <braunr> 1046
-    <braunr> oh my
-    <braunr> in comparison, a firefox instance has less than 500 on linux
-    <jkoenig> 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?)
-    <braunr> jkoenig: sorry for being confusing, it's not that at all
-    <jkoenig> (btw feel free to tell me to just go read the source or whatever)
-    <braunr> jkoenig: don't worry
-    <jkoenig> braunr, no problem
-    <braunr> 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
-    <braunr> 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
-
-    <braunr> oh btw, i noticed there are many mappings below the program text
-    <braunr> most notably, the stack
-    <braunr> except for special applications like wine, could this break
-      anything ?
-    <braunr> i also wonder how libraries are mapped, because there is nothing
-      to perform top-down allocations
-    <braunr> which means if the region below the program text is exhausted,
-      libraries could be mapped right after the heap
-    <youpi> it shouldn't break anything except things like wine & libgc, yes
-    <braunr> which could make malloc() fail :/