summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorguy fleury iteriteka <gfleury@disroot.org>2021-01-01 18:10:49 +0100
committerSamuel Thibault <samuel.thibault@ens-lyon.org>2021-01-01 18:10:49 +0100
commit958994c71e18b877869ecb253c2914dfd6f09276 (patch)
tree5888078fb0dcd669d509c66a69e501654d456d2e
parent7b4f7bbabb53b4cc75c95b264eac3c4f62f9e967 (diff)
remove mremap from open_issues
-rw-r--r--open_issues/glibc/mremap.mdwn70
1 files changed, 0 insertions, 70 deletions
diff --git a/open_issues/glibc/mremap.mdwn b/open_issues/glibc/mremap.mdwn
deleted file mode 100644
index c17506d7..00000000
--- a/open_issues/glibc/mremap.mdwn
+++ /dev/null
@@ -1,70 +0,0 @@
-[[!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