sort SEE ALSO;

Add mimmutable(2) libc stub, add & adjust manual pages, and crank the minor.
ok kettenis

man pages: add missing commas between subordinate and main clauses

jmc@ dislikes a comma before "then" in a conditional, so leave those
untouched.

ok jmc@

more trivial .Ar -> .Fa replacements in syscall manuals

document ENOTSUP wxallowed/wxneeded behaviour more clearly; ok kurt

In "4.2BSD System Manual" (/usr/doc/sysman in 4.2BSD source)
mmap(), munman(), madvise() and mprotect() are described as planned for
later releases.

A fully functional mmap(2) supporting shared libr

In "4.2BSD System Manual" (/usr/doc/sysman in 4.2BSD source)
mmap(), munman(), madvise() and mprotect() are described as planned for
later releases.

A fully functional mmap(2) supporting shared libraries first appeared in
SunOS 4.0 along with msync(2). SunOS 4.1 added madvise(3) and replaced
msync(2) with mctl(2) which was was used to implement msync(3), mlock(3)
and munlock(3).

While some of these functions appear as empty or ifdef'd functions in
4.1cBSD and later it was not until the Mach VM was integrated with Net/2
that most of them were implemented. Though the CSRG releases never
supported shared libraries or madvise(). mlock()/munlock() were not in
Net/2 as they were added by hibler in 1993, but were in 4.4BSD.

madvise(2) was implemented for UVM in NetBSD 1.5 and ported to
OpenBSD 2.7.

For now instead of trying to accurately describe when interfaces
first appeared in other systems correct when they were first available
in CSRG or OpenBSD releases, retaining the text in mmap(2) discussing
SunOS 4.0.
madvise(2) 4.4BSD -> OpenBSD 2.7
mmap2(2) 4.4BSD -> 4.3BSD Net/2
mprotect(2) 4.4BSD -> 4.3BSD Net/2
msync(2) 4.4BSD -> 4.3BSD Net/2
munmap(2) 4.1cBSD -> 4.3BSD Net/2

show more ...

Adjust history text.

A fully functional mmap() system call first appeared in SunOS 4.0 and
has been available since 4.4BSD.

wording from and ok schwarze@ input from deraadt@

replace links to uvm(9) to uvm_init(9); ok mpi

No specific called "exec(3)", so move primary manpage to a name which
does exist -- execv(3). Still call this a family but without "Nm".
Adjust Xr in various pages to refer to the precise function u

No specific called "exec(3)", so move primary manpage to a name which
does exist -- execv(3). Still call this a family but without "Nm".
Adjust Xr in various pages to refer to the precise function used
rather than the family, in most cases the semantics of execve(2) are
being referenced, so change the Xr.
ok jmc

show more ...

Document MAP_CONCEAL. Prompted by jmc@. ok otto@ schwarze@.

mincore() is a relic from the past, exposing physical machine information
about shared resources which no program should see. only a few pieces of
software use it, generally poorly thought out. the

mincore() is a relic from the past, exposing physical machine information
about shared resources which no program should see. only a few pieces of
software use it, generally poorly thought out. they are being fixed, so
mincore() can be deleted.
ok guenther tedu jca sthen, others

show more ...

macro fix;

Document how MAP_STACK will be used. All stacks must be mmap'd with
this attribute. The kernel does so for main-process stacks at execve() time,
pthread stack functions do so for new stacks, and st

Document how MAP_STACK will be used. All stacks must be mmap'd with
this attribute. The kernel does so for main-process stacks at execve() time,
pthread stack functions do so for new stacks, and stacks provided to
sigaltstack() and other user-provided stacks will need to be allocated
in that way.
Not required yet, but paving the way.
Work done with stefan

show more ...

Adjust references for sysctl(3) to sysctl(2)

Accessing a mmap(2)ed file behind its end should result in a SIGBUS
according to POSIX. Bring regression test and kernel in line for
amd64 and i386. Other architectures have to follow.
OK deraadt@

Accessing a mmap(2)ed file behind its end should result in a SIGBUS
according to POSIX. Bring regression test and kernel in line for
amd64 and i386. Other architectures have to follow.
OK deraadt@ kettenis@

show more ...

Not all devices support mmap, document EINVAL in this case too.
OK deraadt@

shuffle back: wxabort is described in sysctl(3);

repair Xr, and point to sysctl(8) instead because sysctl(3) fails to
document kern.wxabort
from michael reed

W^X violations are no longer permitted by default. A kernel log message
is generated, and mprotect/mmap return ENOTSUP. If the sysctl(8) flag
kern.wxabort is set then a SIGABRT occurs instead, for

W^X violations are no longer permitted by default. A kernel log message
is generated, and mprotect/mmap return ENOTSUP. If the sysctl(8) flag
kern.wxabort is set then a SIGABRT occurs instead, for gdb use or coredump
creation.

W^X violating programs can be permitted on a ffs/nfs filesystem-basis,
using the "wxallowed" mount option. One day far in the future
upstream software developers will understand that W^X violations are a
tremendously risky practice and that style of programming will be
banished outright. Until then, we recommend most users need to use the
wxallowed option on their /usr/local filesystem. At least your other
filesystems don't permit such programs.

ok jca kettenis mlarkin natano

show more ...

Add MAP_ANONYMOUS as a synonym for MAP_ANON, per POSIX proposal

ok miod

Various small typographic fixes for mman.h manual pages:

Use .Fn instead of .Nm as appropriate
Use .In for include lines
Use .Rv -std where possible
Use .Xr to refer to functions from other manual p

Various small typographic fixes for mman.h manual pages:

Use .Fn instead of .Nm as appropriate
Use .In for include lines
Use .Rv -std where possible
Use .Xr to refer to functions from other manual pages
Remove extraneous sys/types.h include

More substantive changes to follow.

Discussed with schwarze

show more ...

Sync description of PROT_* flags between mmap.2 and mprotect.2

ok guenther

zap unneccessary punctuation;

OpenBSD supports mmap() on block special files too.

Split out mmap's compatibility flags into a separate section, so users
aren't misled into thinking they're useful on OpenBSD.