>They also provide atomic read/writes to local files at
>arbitrary offset and are useful for multithreaded apps.

>May be we should just generalize readv/writev to also
>specify offsets.  Something like

>struct vio {
>	void   *vio_base;
>	size_t  vio_len;
>	off_t   vio_off;
>};

>ssize_t vread(int d, const struct vio* vec, int cnt);
>ssize_t vwrite(int d, const struct vio* vec, int cnt);

Being a newbie to NetBSD (AIX and BSD/OS are the kernels I know best)
maybe I should just shush, but that just ain't my way...

The first problem I see is that we have another file system extension
that cannot be effectively supported by network filesystems and future
concurrent access filesystems (ie, multiple SCSI initiators on a single
bus).

The next problem I see is retrofitting all current code which uses
readv/writev to set vio_off to -1 or some other value to indicate
"don't seek on this call".  This item could be resolved by the adition
of an fcntl (or whatever) call to enable the use of the vio_off field.

The next problem I see relates to portability, many folks (myself
included) assume similar semantics go with system calls by the same
name.  Admitedly, references to element vio_off in the code should
be a dead givaway, but...

Overall, I beleive a new syscall would be the least intrusive way
of dealing with the new functionality.

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?

The bright side of things is that these would be pretty trivial to
implement.

-michael
-- 
Michael Galassi   nerd@percy.rain.com   http://percy.rain.com/~nerd/