Re: [Qemu-devel] [PATCH 2/6] change vectored block I/O API to plain iovecs

[Avi Kivity <avi@redhat.com>]

Christoph Hellwig wrote:

 

>> virtio gets its iovecs through a hacky (and incorrect, try >=4G) 
>> method.  IMO virtio should be fixed to use the dma api, at which point 
>> it will start to use QEMUIOVector anyway,
>>     
>
> I would not call it hacky an incorrect.  And the current dma API
> certainly won't work due to the layering between the generic virtio
> layer and virtio-block.
>   

It is not incorrect, as Anthony pointed out.  It's hacky in that it 
touches deep qemu internals.

The dma api has two layers; while the upper layer (in dma-helpers.c) is 
too high level for virtio, the lower level ought to work.

>> Internally yes, but why should bdrv_* not use QEMUIOVector?  That API 
>> isn't very interested in posix.
>>     
>
> Because it makes life a lot easier.  We already pass the length in
> sector units anyway.  While QEMUIOVector could replace instead of
> currently duplicate it that would mean another translation between
> byte and sector units at the block level.  And then comes the issue
> of feeding in iovecs - there is the case of iovecs coming from other
> layers like virtio-blk

virtio-blk could simply gather iovecs through QEMUIOVector

>  and the more important one of just creating
> one-entry static iovecs in many places.  These would mean another
> dynamic allocation and lots of API churn.
>   

    QEMUStaticIOVector qiov;

    qemu_static_iovector_init(&qiov, data, len);
    some_random_function(&qiov.iov, ...);

Of course we need not to free non-owned iovecs.

> Keep the QEMUIOVector as a nice abstraction for the memory-managment
> issues in dma-helper.c but I think as an API for passing data (which
> doesn't care about how the iovec array is allocated) they aren't
> very helpful.
>   

They allow dropping two extra parameters, but I agree no huge benefit.  
I still like them.

-- 
error compiling committee.c: too many arguments to function