* Map the message buffer with access_type = VM_PROT_READ|VM_PROT_WRITE `just
because'.
* Map the file system buffers with access_type = VM_PROT_READ|VM_PROT_WRITE to
avoid possible problems with pagemove().
* Do not use VM_PROT_EXEC with either of the above.
* Map pages for /dev/mem with access_type = prot. Also, DO NOT use
pmap_kenter() for this, as we DO NOT want to lose modification information.
* Map pages in dumpsys() with VM_PROT_READ.
* Map pages in m68k mappedcopyin()/mappedcopyout() and writeback() with
access_type = prot.
* For now, bus_dma*(), pmap_map(), vmapbuf(), and similar functions still use
access_type = 0. This should probably be revisited.
"BUS_SPACE_ALIGNED_POINTER()".
Equal to the param.h "ALIGNED_POINTER()" normally, but obeys additional
requirements of the bus_space_xxx_n() macros. (BUS_SPACE_DEBUG)
minor of libc and the major of libutil). For little-endian architectures
merge the bnswap() assembly versions with nto* and hton* using symbols
aliasing. Use symbol renaming for the bswap function in this case to avoid
namespace pollution.
Declare bswap* in machine/bswap.h, not machine/endian.h. For little-endian
machines, common code for inline macros go in machine/byte_swap.h
Sync libkern with libc.
Adjust #include in kernel sources for machine/bswap.h.
- returned EOPNOTSUPP rather than -1.
- no check for negative offset.
many of these fix potential security problems in these drivers.
XXX XXX XXX
the d_mmap cdev routine should be changed to have a prototype like:
paddr_t (*d_mmap) __P((dev_t, off_t, int));
by someone!
-sys/lib/libkern builds as library per default (as it was documented all
the time)
-ports able to LKM set "KERN_AS=obj" explicitely in their Makefiles
(for now; should depend on actual "option LKM" or -better- functions
included for LKM use should be pulled in by a stub)
-always link libcompat before libkern - libkern stuff can be referred to
by libcompat, but not the other way
u-area in machine-dependent code. Instead, call exit2() to schedule
the reaper to free them for us, once it is safe to do so (i.e. we are
no longer running on the dead proc's vmspace and stack).
