Messages in this thread |  | | From | Alan Cox <> | Subject | Re: writev() "bug" | Date | Mon, 3 Jun 1996 09:30:29 +0100 (BST) |
| |
> This doesn't quite qualify as a bug, but it's something I think should > be changed. Currently writev(3) allows a maximum of 8 iov's in the io > vector; if more than 8 are specified, it returns EINVAL. IMHO, this > is far too small, especially for an arbitrary limit: SunOS supports up > to 16, and OSF/1 (aka Digital UNIX) supports up to 1024. I'd like to > see MAX_IOVEC increased to at least 16, and preferably more than that.
Large numbers of iovecs would mean putting a lot of kernel changes in as we just shove a kernel space mapped image of the iovec list on the stack. I've not got any applications that have moaned at eight so I feel reasonably happy with this at the moment.
> Also, note that MAX_IOVEC is not the correct name for this parameter: > a brief survey (consisting of DEC OSF/1 and NetBSD-current) seems to > indicate that UIO_MAXIOV is the right name.
I've a feeling thats the proper symbol name in the posix draft too. I'll have a read. MAX_IOVEC is meant to be a kernel internals define.
|  |