size_t changes and 32/64-bit, kernel uio_resid type changed.

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    size_t has been changed to unsigned long (and ssize_t to long).  I may
    revert this prior to the release if we hit pkgsrc problems.  The change
    will be kept for 64-bit machines.

    The change on 32 bit machines seems to do a pretty good job generating
    compiler warnings on 32-bit machines for code that will break on
    64-bit machines.  Because of this I think it is worth seeing how badly
    pkgsrc breaks with the change.  If it breaks too much we will revert
    it on 32 bit machines.

    --

    The kernel uio structure's uio_resid field has been changed from a
    signed integer to a size_t (aka unsigned long).  On 32 bit machines
    the 2G limit on VM functions like mmap() has been removed.  I/O
    functions which return ssize_t (which is signed) still impose a 2G
    limit but all the code inside the kernel has been refactored to use
    the whole 4G space.

    On 64 bit systems all prior 2G size limitations for both I/O and
    VM system calls have been removed.  size_t's full range may be used.

    Since it is possible to mmap() multiple terrabytes and issue a single
    write() system call covering the entire space, the HAMMER filesystem
    has been adjusted to allow read() and write() calls to be interrupted
    for I/O sizes greater then 100MB.  I don't think we have a choice here,
    it is too easy to DOS a machine if they aren't interruptable for the
    large-I/O-size case.

    I have only done a little testing with hugely-sized reads and writes
    to files, pipes, and socket pairs.  I have not tested e.g. sendfile().

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>