Messages in this thread |  | | Subject | Re: writev() "bug" | From | Marc Unangst <> | Date | Mon, 03 Jun 1996 09:35:36 -0400 |
| |
Alan Cox writes: > 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.
Hrm, okay. I didn't realize it would be difficult to change this. At any rate, I *have* had problems with eight: sendpage 7a tries to write out 11 items using writev(). For some reason, it worked when I was running 1.2.13, but broke when I upgraded to pre2.0.9. I can't figure out *why* it worked, since as far as I can tell 1.2.13 didn't even support writev(). (At least, I couldn't find any code in the kernel to handle it. I'm still using the same libc version, 5.2.18, so unless libc has adaptive code that emulates writev() for older kernels, I can't find the code that would have implemented it.)
I think that there is still a lot of SunOS-centric code out there that will blindly assume it can write up to 16 iov's in one call. For that reason, I don't think Linux should go smaller than that unless absolutely necessary. Why is it any harder to shove 64 bytes onto the stack (8 iov structs) than 128 bytes (16 iov structs)? I wouldn't think you would run into problems until you get much larger and start running into the VM page size.
-Marc
|  |