why limit of 16 iovec's in readv/writev?

[Chris Torek]

In article <473 at siswat.UUCP> buck at siswat.UUCP (A. Lester Buck) writes:
>[why is there a limit of 16 iovec vectors]?

Since the array of iovec structures must exist in kernel space (for
reasons having to do with cleanliness and security in the rest of the
kernel), they are `created' on the kernel stack during a sendmsg() or
recvmsg() (or readv() or writev()) call, and the user values are
copied into this local array.  It has a `reasonable' bounded size.

4.4BSD already uses the kernel malloc for readv() and writev(),
and allows 8 `free' iovec structures (on the stack) or up to
1024 `expensive' iovec structures (via malloc+io+free).  The same
could be done for sendmsg and recvmsg, but I suspect there is a
bit less incentive.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at cs.umd.edu	Path:	uunet!mimsy!chris