Re: Last call: removing the INT_MAX limit on max i/o size
* Konstantin Belousov kostik...@gmail.com [120217 17:54] wrote: This is a notification to allow you to comment on the patch before the commit. I will commit the latest version of the patch to remove the limitation of the maximal i/o size for read/write syscalls to INT_MAX in the beginning of the next week. The change is available at http://people.freebsd.org/~kib/misc/uio_resid.10.patch various versions of it were discussed with Bruce Evance and David Schultz. Patch does not enable SSIZE_MAX-sized i/o by default, hiding this under debug.iosize_max_clamp sysctl. Effectively, the patch becomes the pass to change various ints into ssize_t. I always wonder if it's worth defining a type for this, resid_t or something, therefor you could use some tricks to generate warnings when it's cast to a type that normally would not generate warnings but could cause some loss or issue otherwise. Probably not. -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Last call: removing the INT_MAX limit on max i/o size
* Poul-Henning Kamp p...@phk.freebsd.dk [120218 00:34] wrote: In message 20120218074655.gf31...@elvis.mu.org, Alfred Perlstein writes: I always wonder if it's worth defining a type for this, resid_t or something, Wouldn't that naturally be size_t ? I think that makes sense. I was thinking along the lines of making sure that functions that take a resid_t aren't actually being passed the wrong ssize_t, but really that's probably too much fence and just would obfuscate things. -- - Alfred Perlstein .- VMOA #5191, 03 vmax, 92 gs500, 85 ch250, 07 zx10 .- FreeBSD committer ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Last call: removing the INT_MAX limit on max i/o size
In message 20120218074655.gf31...@elvis.mu.org, Alfred Perlstein writes: I always wonder if it's worth defining a type for this, resid_t or something, Wouldn't that naturally be size_t ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Last call: removing the INT_MAX limit on max i/o size
This is a notification to allow you to comment on the patch before the commit. I will commit the latest version of the patch to remove the limitation of the maximal i/o size for read/write syscalls to INT_MAX in the beginning of the next week. The change is available at http://people.freebsd.org/~kib/misc/uio_resid.10.patch various versions of it were discussed with Bruce Evance and David Schultz. Patch does not enable SSIZE_MAX-sized i/o by default, hiding this under debug.iosize_max_clamp sysctl. Effectively, the patch becomes the pass to change various ints into ssize_t. pgpmSkr7UMrvo.pgp Description: PGP signature
