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@...>
