qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v3 09/12] iov: add iov_get_ptr() to reference ve


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH v3 09/12] iov: add iov_get_ptr() to reference vector data
Date: Thu, 22 Nov 2012 13:14:12 +0200

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]