rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn

1 files changed, 70 insertions, 0 deletions

diff --git a/service_solahart_jakarta_selatan__082122541663/glibc/mremap.mdwn b/service_solahart_jakarta_selatan__082122541663/glibc/mremap.mdwn
new file mode 100644
index 00000000..c17506d7
--- /dev/null
+++ b/service_solahart_jakarta_selatan__082122541663/glibc/mremap.mdwn
@@ -0,0 +1,70 @@
+[[!meta copyright="Copyright © 2011, 2012 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_glibc]]
+
+The Hurd does not currently support the `mremap` function.
+
+For the `MREMAP_MAYMOVE` case it is easy to work around; see
+`[binutils]/gold/mremap.c`, for example.
+
+Also see the discussion of [[glibc/mmap]].
+
+[[!toc]]
+
+
+# IRC, freenode, #hurd, 2011-01-12
+
+    <antrik> maybe it would be easiest actually to implement mremap()?...
+    <braunr> antrik: i'm nto sure
+    <braunr> antrik: implementing mremap could be relatively easy to do
+      actually
+    <braunr> antrik: IIRC, vm_map() supports overlapping
+    <antrik> braunr: yes, I think so too
+    <antrik> braunr: haven't checked, but I have a vague recollection that the
+      fundamentals are pretty much there
+
+[[!taglink open_issue_glibc]]: check if it is possible to implement `mremap`.
+[[I|tschwinge]] remember some discussion about this, but have not yet worked on
+locating it.  [[Talk to me|tschwinge]] if you'd like to have a look at this.
+
+
+# IRC, OFTC, #debian-hurd, 2012-06-19
+
+    <bdefreese> OK, how the heck do you get an undefined reference to mremap?
+    <youpi> simply because we don't have it
+    <pinotree> mremap exists only on linux
+    <bdefreese> It's in sys/mman.h
+    <pinotree> on linux?
+    <bdefreese> No, on GNU/Hurd
+    <bdefreese>  /usr/include/i386-gnu/sys/mman.h
+    <youpi> that's just the common file with linux
+    <youpi> containing just the prototype
+    <youpi> that doesn't mean there's an implementation behind
+    <pinotree> youpi: hm no, linux has an own version
+    <youpi> uh
+    <bdefreese> Ah, aye, I didn't look at the implementation.. :(
+    <youpi> it's then odd that it was added to the generic sys/mman.h :)
+    <bdefreese> Just another stub?
+    <pinotree> ah, only few linux archs have own versions
+    <youpi> for the macro values I guess
+    <pinotree> http://paste.debian.net/175173/ on glibc/master
+    <bdefreese> Hmm, so where is MREMAP_MAYMOVE coming in from?
+    <youpi> rgrep on a linux box ;)
+    <youpi> <bits/mman.h>
+    <youpi> but that's again linuxish
+    <bdefreese> Aye but with us having that in the header it is causing some
+      code to be run which utilizes mremap.  If that wasn't defined we wouldn't
+      be calling it.
+    <youpi> ah
+    <youpi> we could try to remove it indeed
+    <bdefreese> Should I change the code to #ifdef MREMAP_MAYMOVE & !defined
+      __GNU__?
+    <youpi> no, I said we could remove the definition of MREMAP_MAYMOVE itself