On Thu, Nov 22, 2012 at 11:54:49AM +0100, Paolo Bonzini wrote:
> Il 22/11/2012 11:38, Michael S. Tsirkin ha scritto:
> >> > The code is a little simpler, because we know the footer is 1 byte only.
> >
> > Yes but the APIs don't make sense in the generic case
> > of >1 byte: users will have to code up two paths for when
> > the buffer they want to access gets scattered across.
>
> That would be premature optimization; with >1 byte you just use
> iov_from/to_buf.
If the API makes it very clear that it only works for 1 byte
I would have no objection.
> BTW, something like this function is also useful for the broken SCSI
> outhdr ("the CDB starts after the common outhdr and is in a single
> iovec"). But the API must be changed slightly, as in my answer to Stefan.
The scsi command is special in that the length is
iov_length. It's all legacy anyway so I think we can
just assume it's the second s/g entry:
iov[1].iov_length.
We should probably have a wrapper that gets it
after checking iov_cnt > 1.
size_t iov_get_seg_length(...)
{
assert(iov_cnt <= idx);
return iov[idx].iov_length;
}
Rusty says he'll put the length of the command
in the buffer in the future, so we will have
if (new_cmd_feature)
iov_to_buf(.... &len)
else
len = iov_get_seg_length
> > If the point is to avoid scanning iov vector when data is towards the
> > end of the iov, then this does sound reasonable. In that case IMHO we
> > should just have accessors that work back from end of the iov. E.g.
> >
> > size_t iov_from_buf_end(const struct iovec *iov, unsigned int iov_cnt,
> > size_t offset, const void *buf, size_t bytes)
>
> That's also a possibility.
>
> Paolo
