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"
Re: Last call: removing the INT_MAX limit on max i/o size
* Poul-Henning Kamp [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
* Konstantin Belousov [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"
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
