[Top][All Lists]

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

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

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [RFC] introduce a dynamic library to expose qemu block API
Date: Wed, 18 Jul 2012 06:42:24 -0400 (EDT)

> Whether to provide sync and/or async access is a key question.


> 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


reply via email to

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