diff options
Diffstat (limited to 'open_issues')
| -rw-r--r-- | open_issues/placement_of_virtual_memory_regions.mdwn | 16 | ||||
| -rw-r--r-- | open_issues/rm_fr.mdwn | 12 |
2 files changed, 27 insertions, 1 deletions
diff --git a/open_issues/placement_of_virtual_memory_regions.mdwn b/open_issues/placement_of_virtual_memory_regions.mdwn index 95b9e545..39478f20 100644 --- a/open_issues/placement_of_virtual_memory_regions.mdwn +++ b/open_issues/placement_of_virtual_memory_regions.mdwn @@ -10,7 +10,7 @@ License|/fdl]]."]]"""]] [[!tag open_issue_gnumach]] -IRC, freenode, #hurd, 2011-07-13 +# 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 ? @@ -87,3 +87,17 @@ IRC, freenode, #hurd, 2011-07-13 <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 :/ diff --git a/open_issues/rm_fr.mdwn b/open_issues/rm_fr.mdwn index 89a803ab..aab52d97 100644 --- a/open_issues/rm_fr.mdwn +++ b/open_issues/rm_fr.mdwn @@ -25,3 +25,15 @@ really waits for all I/Os, which basically means strictly serializing file removals: remove one file, wait for the disk to have done it (~10ms), remove the next one, etc. I guess this is for safety reasons against crashes, but isn't the sync option there for such kind of + + +# IRC, freenode, #hurd, 2011-07-23 + + <antrik> youpi: hm... async deletion does have one downside: I just removed + something to make space, and retried the other command immediately + afterwards, and it still said "no space left on device"... a few seconds + later (after the next regular sync I suppose?) it worked + <youpi> well, that's sorta expected, yes + <youpi> we get the same on Linux + <youpi> Mmm, on second thought, I'm not sure how that can happen + <youpi> the asynchronous thing is for disk writes, not cache writes |