fcntl(F_SETFL) invokes the FIONBIO and FIOASYNC ioctls internally, so
the memory devices (/dev/null, /dev/zero, etc) need to permit them.

problem noted, tweak, and testing by jeremy@
ok deraadt@

Make a move towards ending 4 decades of kernel snooping.

Add sysctl kern.allowkmem (default 0) which controls the ability to open
/dev/mem or /dev/kmem at securelevel > 0. Over 15 years we converted 99%
of utilities in the tree to operate on sysctl-nodes (either by themselves
or via code hiding in the guts of -lkvm).

pstat -d and -v & procmap are affected and continued use of them will
require kern.allowkmem=1 in /etc/sysctl.conf. acpidump (and it's
buddy sendbug) are affected, but we'll work out a solution soon.

There will be some impact in ports.

ok kettenis guenther

bring the light of ansi to a few more files

Convert to uiomove().
ok guenther@

First step towards making uiomove() take a size_t size argument:
- rename uiomove() to uiomovei() and update all its users.
- introduce uiomove(), which is similar to uiomovei() but with a size_t.
- rewrite uiomovei() as an uiomove() wrapper.
ok kettenis@

Massive overhauling of the m88k pmap, though I can't pretend it's a new pmap
since a large part of the structures and logic remains.

Since m88k has separate supervisor/user spaces, we can map physical memory 1:1
in supervisor space, and have the kernel virtual address space start from the
end of physical memory.

This allows us to switch to __HAVE_PMAP_DIRECT. And to get rid of the double
mapped sdt, since now their virtual and physical addresses will always match.

The upper bound of the kernel virtual memory space is now platform dependent,
until the code which relies upon some hardware devices being mapped 1:1 in
supervisor mode is updated to no longer require this (this is mainly a PITA on
luna88k, where onboard devices start at 0x40000000, leaving only 1GB of KVA at
the moment - still much better than the previous 512MB).

Tested on mvme88k only (187, 188, 197LE, 197DP). Other platforms ought to
work, aviion will be checked shortly and fixed if necessary. No known
OpenBSD/luna88k system in working condition at the moment.