Re: [Qemu-devel] [RFC] introduce a dynamic library to expose qemu block API

[Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>]

On Wed, Jul 18, 2012 at 06:42:24AM -0400, Paolo Bonzini wrote:
> > Synchronous APIs are great for writing dedicated tools like dd, cp,
> > convert, etc.
> > 
> > Asynchronous APIs are essential for integrating image file I/O into
> > event-driven programs like libvirt.  Here, the ability to do other
> > things while image file I/O is in progress is a requirement.  It may
> > also be necessary to cancel or timeout if an operation is not making
> > progress or the user decides to stop it.
> > 
> > I think we need to provide both sync and async.  Libraries like
> > libssh2 and libcurl already do this so their APIs can be used as a
> > starting point for async I/O.
> 
> If we want to provide an asynchronous API, the easiest thing would
> be to provide a GSource and that's it.  That would even make sense for
> QEMU itself, in fact.
> 
> What I'm worried about, is how to support _both_ synchronous and
> asynchronous access.  I'd like the library to be clean of things like
> qemu_aio_wait() and qemu_aio_flush(), at least in the beginning.
> That's why I think async can come later, once we actually get
> applications needing it.  Right now, libvirt's requirements are
> simple (e.g. probing the backing file chain) and would be synchronous
> anyway.

Yes, qemu_aio_wait() and qemu_aio_flush() are ugly.

Starting with sync makes sense, it's a convenient API to have even if we
add async later.

Stefan