Ulrich Drepper wrote: > If they are in the kernel there is no reason not to export them from > glibc. Great. > But I have a general comment about all kinds of read syscalls. > If think they have been misdesigned from day one and if we are going to > add new ones we might want to fix them. > > The problem is that they don't allow for zero-copy operations in enough > cases. The kernel is not free to store the data wherever it wants even > if the userlevel code is fine with that. [ ... more text snipped ... ] I do see the point in adding a interface like this ... > ssize_t readz (int fd, void *buf, size_t len, void **res) ... to help the kernel do zero-copy I/O. I think system calls for vector I/O are *not* the right place for that though. Usually applications use vectored I/O because they *do* care about the place the data is stored, because vectored I/O allows them to avoid copying data within the application. cheers, Gerd -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
