Re: [Qemu-devel] [PATCH] RFC: Add new block driver for the VDI format

[Stefan Weil <weil@mail.berlios.de>]

Anthony Liguori schrieb:
> Stefan Weil wrote:
>> Hello,
>>
>> this mail will be followed by two patches which
>> allow QEMU to create, read and write VDI images.
>> VDI is the native image format of SUN's VirtualBox emulator.
>>
>> The code was written from scratch for QEMU, while earlier patches
>> sent to Qemu-devel were wrappers for code from VirtualBox. See
>> http://lists.gnu.org/archive/html/qemu-devel/2008-07/msg00366.html
>> for those patches.
>>
>> Patch 1 adds uuid support to QEMU and can be used independent of
>> the second patch (look for uuid in vl.c, for example).
>>
>> Patch 2 adds the VDI block driver. It only needs uuid support
>> when a new image is created (without uuid, it will create an image
>> with zeroed "uuid" values), so this second patch is semi-independent
>> of the first.
>>   
>
> I'd really like to get rid of synchronous IO functions in the block
> layer.  One way to do this is to insist that all new block drivers
> only implement the AIO functions.
>
> I think we should make this decree but I'd like to know if other
> people think this is unreasonable first.  One potential model of block
> drivers would involve synchronous IO and threads.  I'm not a big fan
> of that model and I don't think it's an easy conversion from today's
> synchronous IO drivers to that model because the locking and
> re-entrance needs careful consideration.
>
> Since it looks like you're caching the full offset table in memory,
> and it's a single level, making it asynchronous should be very easy to
> do.
>
> Regards,
>
> Anthony Liguori
>

Yes, at least it should be straight forward to do.
I planned to switch to AIO in a second stage.

It would help if you could already commit the synchronous version
as soon as the endianess issue (detected by Kevin Wolf, thanks)
and an additional bug in the write code are fixed
(code is ready, but still untested - a patch will follow this week).

I don't plan to change the code's license from GPL to MIT.
This is a matter of my personal taste. Is this a problem
for new block driver code?

Regards,

Stefan Weil