[lkml]   [1996]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: writev() "bug"
> 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.

 \ /
  Last update: 2005-03-22 13:37    [W:0.084 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site