Re: [Qemu-devel] [RFC PATCH 1/1] ceph/rbd block driver for qemu-kvm

[Avi Kivity <avi@redhat.com>]

On 05/25/2010 05:02 PM, Anthony Liguori wrote:
> On 05/25/2010 08:57 AM, Avi Kivity wrote:
>> On 05/25/2010 04:54 PM, Anthony Liguori wrote:
>>> On 05/25/2010 08:36 AM, Avi Kivity wrote:
>>>>
>>>> We'd need a kernel-level generic snapshot API for this eventually.
>>>>
>>>>> or (2) implement BUSE to complement FUSE and CUSE to enable proper 
>>>>> userspace block devices.
>>>>
>>>> Likely slow due do lots of copying.  Also needs a snapshot API.
>>>
>>> The kernel could use splice.
>>
>> Still can't make guest memory appear in (A)BUSE process memory 
>> without either mmu tricks (vmsplice in reverse) or a copy.  May be 
>> workable for an (A)BUSE driver that talks over a network, and thus 
>> can splice() its way out.
>
> splice() actually takes offset parameter so it may be possible to 
> treat that offset parameter as a file offset.  That would essentially 
> allow you to implement a splice() based thread pool where splice() 
> replaces preadv/pwritev.

Right.

(note: need splicev() here)

>
> It's not quite linux-aio, but it should take you pretty far.   I think 
> the main point is that the problem of allowing block plugins to qemu 
> is the same as block plugins for the kernel.  The kernel doesn't 
> provide a stable interface (and we probably can't for the same 
> reasons) and it's generally discourage from a code quality perspective.

The kernel does provide a stable interface for FUSE, and it could 
provide a stable interface for ABUSE.  Why can the kernel support these 
and qemu can't support essentially the same thing?

> That said, making an external program work well as a block backend is 
> identical to making userspace block devices fast.

More or less, yes.

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