Re: Rename MAP_ANON to MAP_ANONYMOUS
On Mon, Jun 30, 2014 at 2:47 PM, Ingo Schwarze schwa...@usta.de wrote: so in a nutshell, mmap(2) was originally a BSD idea and first implemented in SunOS? And there is no doubt that *BSD always had MAP_ANON and never MAP_ANONYMOUS and that SunOS primarily defines MAP_ANON and MAP_ANONYMOUS only for /* (source compatibility) */, right? And that the earliest occurence of MAP_ANONYMOUS we found so far is Linux (1994)? And that 4.4BSD was released with MAP_ANON before that (1993)... I've reaffirmed that OpenBSD's stance is that we'd prefer that MAP_ANON be standardized, explained the commit history of MAP_ANON and MAP_ANONYMOUS (thanks Ingo!), and also pointed out that Advanced Programming in the UNIX Environment recommends MAP_ANON: http://austingroupbugs.net/view.php?id=850#c2299 I'll update the thread if anything new develops. Next Austin Group teleconference is July 10.
Rename MAP_ANON to MAP_ANONYMOUS
I filed an enhancement request with the Austin Group to standardize an mmap() flag for mapping anonymous memory. I proposed standardizing MAP_ANON, but the current proposal is to standardize MAP_ANONYMOUS instead, as that seems to be the more common definition and usage: http://austingroupbugs.net/view.php?id=850 All else equal, I prefer MAP_ANON as it's shorter and it's also the original BSD name; but I prefer having a standardized name even more. If anyone objects and has convincing arguments for why POSIX should standardize MAP_ANON instead, feel free to either comment on the above bug, or just express them here and I'll proxy them appropriately. Otherwise, diff below renames MAP_ANON to MAP_ANONYMOUS, and redefines MAP_ANON as an alias for MAP_ANONYMOUS. Index: sys/sys/mman.h === RCS file: /home/matthew/cvs-mirror/cvs/src/sys/sys/mman.h,v retrieving revision 1.25 diff -u -p -r1.25 mman.h --- sys/sys/mman.h 27 Jun 2014 20:50:43 - 1.25 +++ sys/sys/mman.h 27 Jun 2014 21:35:47 - @@ -56,7 +56,8 @@ */ #defineMAP_FIXED 0x0010 /* map addr must be exactly as requested */ #define__MAP_NOREPLACE 0x0800 /* fail if address not available */ -#defineMAP_ANON0x1000 /* allocated from memory, swap space */ +#defineMAP_ANONYMOUS 0x1000 /* allocated from memory, swap space */ +#defineMAP_ANONMAP_ANONYMOUS /* original BSD spelling */ #defineMAP_FLAGMASK0x1ff7 Index: lib/libc/sys/mmap.2 === RCS file: /home/matthew/cvs-mirror/cvs/src/lib/libc/sys/mmap.2,v retrieving revision 1.48 diff -u -p -r1.48 mmap.2 --- lib/libc/sys/mmap.2 27 Jun 2014 22:51:20 - 1.48 +++ lib/libc/sys/mmap.2 28 Jun 2014 00:01:25 - @@ -120,7 +120,7 @@ Sharing, mapping type, and options are s .Fa flags argument by OR'ing the following values. Exactly one of the first two values must be specified: -.Bl -tag -width MAP_PRIVATE -offset indent +.Bl -tag -width MAP_ANONYMOUS -offset indent .It Dv MAP_PRIVATE Modifications are private. .It Dv MAP_SHARED @@ -128,11 +128,11 @@ Modifications are shared. .El .Pp Any combination of the following flags may additionally be used: -.Bl -tag -width MAP_PRIVATE -offset indent -.It Dv MAP_ANON +.Bl -tag -width MAP_ANONYMOUS -offset indent +.It Dv MAP_ANONYMOUS Map anonymous memory not associated with any specific file. The file descriptor used for creating -.Dv MAP_ANON +.Dv MAP_ANONYMOUS must currently be \-1 indicating no name is associated with the region. .It Dv MAP_FIXED @@ -156,7 +156,16 @@ source compatibility with code written f but are not recommended for use in new .Ox code: -.Bl -tag -width MAP_PRIVATE -offset indent +.Bl -tag -width MAP_ANONYMOUS -offset indent +.It Dv MAP_ANON +Original name for +.Dv MAP_ANONYMOUS , +as introduced by +.Bx . +On +.Ox +this is an alias for +.Dv MAP_ANONYMOUS . .It Dv MAP_COPY Modifications are private and, unlike .Dv MAP_PRIVATE ,
Re: Rename MAP_ANON to MAP_ANONYMOUS
On Mon, Jun 30, 2014 at 10:42 AM, Mark Kettenis mark.kette...@xs4all.nl wrote: Solaris documents MAP_ANON in its man page, and defines MAP_ANONYMOUS as MAP_ANON for source compatibility. Yep, but what about it? Are you suggesting that should affect POSIX's standardization, or that we should do the same thing? I suspect if POSIX standardizes MAP_ANONYMOUS, that Solaris would switch to documenting MAP_ANONYMOUS and providing MAP_ANON for source compat, no?
Re: Rename MAP_ANON to MAP_ANONYMOUS
Date: Mon, 30 Jun 2014 10:53:00 -0700 From: Matthew Dempsky matt...@dempsky.org On Mon, Jun 30, 2014 at 10:42 AM, Mark Kettenis mark.kette...@xs4all.nl wrote: Solaris documents MAP_ANON in its man page, and defines MAP_ANONYMOUS as MAP_ANON for source compatibility. Yep, but what about it? Are you suggesting that should affect POSIX's standardization, or that we should do the same thing? I suspect if POSIX standardizes MAP_ANONYMOUS, that Solaris would switch to documenting MAP_ANONYMOUS and providing MAP_ANON for source compat, no? Yes, I'm saying that this should affect POSIX's standardization. Solaris is where mmap(2) came from. Also, look at: https://github.com/sgminer-dev/sgminer/blob/master/m4/mmap-anon.m4 which contains the following comment: # Detect how mmap can be used to create anonymous (not file-backed) memory # mappings. # - On Linux, AIX, OSF/1, Solaris, Cygwin, Interix, Haiku, both MAP_ANONYMOUS # and MAP_ANON exist and have the same value. # - On HP-UX, only MAP_ANONYMOUS exists. # - On MacOS X, FreeBSD, NetBSD, OpenBSD, only MAP_ANON exists. # - On IRIX, neither exists, and a file descriptor opened to /dev/zero must be # used. This suggests that there is actually a clear majority of systems where only MAP_ANON exists. OK, UnixWare isn't listed here, and perhaps it doesn't provide MAP_ANON for compatibility. But frankly, UnixWare is long dead. Perhaps a few more systems in the only MAP_ANON exists category have moved up to the the both MAP_ANONYMOUS and MAP_ANON exist category. But MacOS X 10.6 is still firmly in the only MAP_ANON exists category. And I'd say MacOS X has a much larger installed base than HP-UX. Regardless of what POSIX decides, I think we should add MAP_ANONYMOUS, but stay true to our heritage and keep MAP_ANON as the primary #define and in the man page.
Re: Rename MAP_ANON to MAP_ANONYMOUS
On Mon, Jun 30, 2014 at 11:31 AM, Mark Kettenis mark.kette...@xs4all.nl wrote: Yes, I'm saying that this should affect POSIX's standardization. Solaris is where mmap(2) came from. The full history is a bit more complicated though. From what I've managed to uncover over the past few days so far: mmap() first appeared in 4.1cBSD [mmap.2] and was scheduled for inclusion in 4.2BSD (1983) [UVM thesis, p36], but didn't actually appear until the 1993 4.4BSD release [UVM thesis, p36]. In the mean time, it was independently reimplemented for SunOS 4 [UVM thesis, p36], and released in 1988 [Wikipedia]. However, SunOS didn't implement MAP_ANON, and instead required users to pass a file descriptor for /dev/zero. In 1994 (prior to Linux's 1.0 release), Linus added support for MAP_ANONYMOUS [https://kernel.googlesource.com/pub/scm/linux/kernel/git/nico/archive/+/0b5e8609bf7e6899c1fea30aa467812d488b6c11%5E%21/#F3]. SunOS 5.8 (Feb 2000) added support for MAP_ANON [http://www.freebsd.org/cgi/man.cgi?query=mmapapropos=0sektion=0manpath=SunOS+5.8arch=defaultformat=html]. I'm not sure when it added MAP_ANONYMOUS support. Also according to Wikipedia, HP-UX is an SVR2 derivative and AIX is an SVR3 derivative. SVR2 and SVR3 were released in 1984 and 1986, respectively, so neither should have inherited MAP_ANON/MAP_ANONYMOUS from SVR/SunOS. I'm not sure when they picked them up. Also, look at: https://github.com/sgminer-dev/sgminer/blob/master/m4/mmap-anon.m4 Yeah, I've seen that, though despite the comment pointing out MAP_ANON is more common, it instead adds a #define MAP_ANONYMOUS MAP_ANON if it notices MAP_ANONYMOUS isn't provided. So ironically, that macro package's widespread use is indicative of code that uses MAP_ANONYMOUS instead of MAP_ANON. :-/
Re: Rename MAP_ANON to MAP_ANONYMOUS
Hi Matthew, so in a nutshell, mmap(2) was originally a BSD idea and first implemented in SunOS? And there is no doubt that *BSD always had MAP_ANON and never MAP_ANONYMOUS and that SunOS primarily defines MAP_ANON and MAP_ANONYMOUS only for /* (source compatibility) */, right? And that the earliest occurence of MAP_ANONYMOUS we found so far is Linux (1994)? And that 4.4BSD was released with MAP_ANON before that (1993)... That does look like a bunch of arguments for the POSIX crowd to swallow, i think. Besides, i dug up some more. Matthew Dempsky wrote on Mon, Jun 30, 2014 at 01:57:20PM -0700: mmap() first appeared in 4.1cBSD [mmap.2] and was scheduled for inclusion in 4.2BSD (1983) [UVM thesis, p36], but didn't actually appear until the 1993 4.4BSD release [UVM thesis, p36]. At least MAP_ANON is definitely a lot older than 1993. The original CSRG commit introducing it looks like this: sys/sys/SCCS/s.mman.h: As 00038/00013/00010 Ad D 7.2 90/12/05 15:28:56 mckusick 6 5 Ac update for new VM And that commit did make it into the 4.3BSD Net/2 release, published on August 20, 1991 (as seen on Kirk's CSRG archive CD). So i'd challenge anybody arguing for MAP_ANONYMOUS to show a published sys/mman.h header file containing that spelling where it was introduced before December 5, 1990. Yours, Ingo Here is version 6 of BSD sys/mman.h as of December 5, 1990: /* * Copyright (c) 1982, 1986 Regents of the University of California. * All rights reserved. The Berkeley software License Agreement * specifies the terms and conditions for redistribution. * * %sccs.include.redist.c% * * %W% (Berkeley) %G% */ /* * Protections are chosen from these bits, or-ed together */ #define PROT_READ 0x04/* pages can be read */ #define PROT_WRITE 0x02/* pages can be written */ #define PROT_EXEC 0x01/* pages can be executed */ /* * Flags contain mapping type, sharing type and options. * Mapping type; choose one */ #define MAP_FILE0x0001 /* mapped from a file or device */ #define MAP_ANON0x0002 /* allocated from memory, swap space */ #define MAP_TYPE0x000f /* mask for type field */ /* * Sharing types; choose one */ #define MAP_COPY0x0020 /* copy region at mmap time */ #define MAP_SHARED 0x0010 /* share changes */ #define MAP_PRIVATE 0x /* changes are private */ /* * Other flags */ #define MAP_FIXED 0x0100 /* map addr must be exactly as requested */ #define MAP_NOEXTEND0x0200 /* for MAP_FILE, don't change file size */ #define MAP_HASSEMPHORE 0x0400 /* region may contain semaphores */ #define MAP_INHERIT 0x0800 /* region is retained after exec */ /* * Advice to madvise */ #define MADV_NORMAL 0 /* no further special treatment */ #define MADV_RANDOM 1 /* expect random page references */ #define MADV_SEQUENTIAL 2 /* expect sequential page references */ #define MADV_WILLNEED 3 /* will need these pages */ #define MADV_DONTNEED 4 /* dont need these pages */
Re: Rename MAP_ANON to MAP_ANONYMOUS
On Mon, Jun 30, 2014 at 2:47 PM, Ingo Schwarze schwa...@usta.de wrote: mmap() first appeared in 4.1cBSD [mmap.2] and was scheduled for inclusion in 4.2BSD (1983) [UVM thesis, p36], but didn't actually appear until the 1993 4.4BSD release [UVM thesis, p36]. At least MAP_ANON is definitely a lot older than 1993. The original CSRG commit introducing it looks like this: sys/sys/SCCS/s.mman.h: As 00038/00013/00010 Ad D 7.2 90/12/05 15:28:56 mckusick 6 5 Ac update for new VM And that commit did make it into the 4.3BSD Net/2 release, published on August 20, 1991 (as seen on Kirk's CSRG archive CD). Thanks. I think that's generally consistent with the years I quoted above, though I suppose the UVM thesis's actually appear wording is arguable. Maybe CDC was referring to how 4.3BSD was a development release, whereas 4.4BSD was a production release? (This release represents an intermediate point in the development of 4.4BSD; [...] This distribution is NOT intended to be used on production systems http://ftp.netbsd.org/pub/NetBSD/misc/release/BSD/BSD-Net1) So i'd challenge anybody arguing for MAP_ANONYMOUS to show a published sys/mman.h header file containing that spelling where it was introduced before December 5, 1990. I don't think MAP_ANONYMOUS is being proposed for standardization because it's perceived to be of older origin than MAP_ANON or anything. I'm pretty sure the focus is instead because it's perceived to have greater 'market share' among present day systems and applications.
Re: Rename MAP_ANON to MAP_ANONYMOUS
I don't think MAP_ANONYMOUS is being proposed for standardization because it's perceived to be of older origin than MAP_ANON or anything. I'm pretty sure the focus is instead because it's perceived to have greater 'market share' among present day systems and applications. Oh come on, the pussy footing is ridiculous. Let's call it what it is. The group is run a handful of Linux proxies. They do not care if incompatibilities are introduced, as long as they are not introduced for Linux.
