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

[Kevin Wolf]

Am 18.07.2012 16:12, schrieb Daniel P. Berrange:
> On Wed, Jul 18, 2012 at 04:02:15PM +0200, Paolo Bonzini wrote:
>> Il 18/07/2012 15:58, Daniel P. Berrange ha scritto:
>>> How is error reporting dealt with
>>
>> These APIs just return errno values.
> 
> Which has led to somewhat unhelpful error reporting in the past. If we're
> designing a library API it'd be nice to improve on this.

But in most cases, errno is what we get from the OS, so we can't do much
more than passing it on. Maybe we can do a bit better with bdrv_open(),
which is relatively likely to fail in qemu rather than in the kernel
because something's wrong with the content of the image.

>>> , and what is the intent around
>>> thread safety of the APIs ?  I'd like to see a fully thread safe
>>> API - multiple threads can use the same 'BlockDriverState *'
>>> concurrently, and thread-local error reporting.
>>
>> This is a bit difficult to provide, since the QEMU block layer itself is
>> not thread-safe.
> 
> Yep, I'd expect that this is something we'd need to fix when turning the
> code into a library.  NB, I don't mean to say QEMU should protect against
> an app doing stupid things like letting 2 threads write to the same area
> of the file at once. That's upto the application. I simply mean that the
> BlockDriverState shouldn't corrupt itself if 2 separate APIs are called
> concurrently on the same instance.

I think it makes sense to make the library thread-safe - and if it only
means taking the global mutex like we do in qemu. I think threading is a
good interface to allow clients to do AIO (even though possibly not the
only one we want to provide), and eventually it will match what qemu is
doing internally.

Kevin