On 06/26/2014 03:28 PM, Matthew Dempsky wrote:
I just reviewed our mmap(2) flags to compare them against Linux, FreeBSD, Solaris, and Darwin's flags. Of the flags listed below, none of them are specified by POSIX, and none of them do anything interesting on OpenBSD: MAP_COPY just gets rewritten to MAP_PRIVATE, and the rest are silently ignored by UVM.Linux FreeBSD Solaris Darwin MAP_COPY no YES* no YES* MAP_RENAME no YES* YES* YES* MAP_NORESERVE YES YES* YES YES* MAP_INHERIT no YES** no no MAP_NOEXTEND no no no YES* MAP_HASSEMAPHORE no YES*** no YES*** MAP_TRYFIXED no no no no * These are defined in the OS's <sys/mman.h>, but are undocumented in their mmap(2) manual, and behave the same as on OpenBSD (i.e., MAP_COPY is an alias for MAP_PRIVATE; the others have no effect). ** MAP_INHERIT is documented in FreeBSD's mmap(2) manual (as "This flag never operated as advertised", which is true on OpenBSD too), but not defined in their <sys/mman.h>. *** MAP_HASSEMAPHORE is documented in FreeBSD and Darwin's mmap(2) manuals and defined in their <sys/mman.h>, but has no effects on either's VM behavior. So MAP_NORESERVE is perhaps necessary/worth keeping around, but the others seem like candidates for removal if nothing in ports needs them. MAP_HASSEMAPHORE is used in rthread_sem.c, but it doesn't do anything, so I suspect it's just cargo culting based on man page misinformation? Are there architectures that actually have restrictions on semaphore memory?
Sun allowed requests for shared memory to be uncached. This was used for DMA and (IIRC) interprocessor communication since adding sufficient memory barriers was painful. I don't remember how to make that request. Geoff Steckel
