> Yup.   I don't like the idea of incompatibly changing the behaviour of
> readv/writev.   On the other hand, we could make the syscalls look
> like this:

I didn't mean changing the readv/writev *interface*.  Since
it is published, there must be at least one person somewhere
depending on it so we can't modify the interface.  That is
why I used the word _generalize_ -- can be done by *adding*
a more general interface.

> int readvo (int d, struct iovec *iov, off_t *offtv, int iovcnt);

This would involve walking two arrays.  Somewhat more
painful.  Whatever the interface, probably the better names
are `preadv/pwritev' since these calls correspond to
pread/pwrite the way readv/writev correspond to read/write.

Michael Galassi wrote:
> The questions become, is the real benefit worth additional kernel
> bloating?   I'm not looking at size as much as interface complexity
> here.  Would the feature realy get used much given its NetBSD only
> support?  Can we reduce the syscall overhead to where performance
> is no longer an issue and provide a more generalized high performance
> threadlocking mechanism such that the atomicity is no longer an issue?

I think the `bloat' is more in the interface.  Actual
implementation is likely to be pretty lean.  Given that
NetBSD/FreeBSD/Linux are more and more being used as
testbeds for new features, if the interface has real value,
it will get adopted by others.  Reducing the syscall
overhead *without* redesigning the entire syscall interface
is a probabky hard -- though `fast call' interface of some
sort would definitely be useful.  We can use other means to
lock things but they usually have a higher cost.  Of course,
we should have some user level locking interface (that falls
back on kernel level locking) too.

--bakul