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

[Avi Kivity]

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