On 07/19/2011 11:47 AM, Daniel P. Berrange wrote:
On Tue, Jul 19, 2011 at 04:30:19PM +0200, Jes Sorensen wrote:
> On 07/19/11 16:24, Eric Blake wrote:
>> [adding the libvir-list]
>> On 07/19/2011 08:09 AM, Jes Sorensen wrote:
>>> Urgh, libvirt parsing image files is really unfortunate, it really
>>> doesn't give me warm fuzzy feelings :( libvirt really should not know
>>> about internals of image formats.
>>
>> But even if you add new features to qemu to avoid needing this in the
>> future, it doesn't change the past - libvirt will always have to know
>> how to parse image files understood by older qemu, and so as long as
>> libvirt already knows how to do that parsing, we might as well take
>> advantage of it.
>
> What has been done here in the past is plain wrong. Continuing to do it
> isn't the right thing to do here.
>
>> Besides, I feel that having a well-documented file format, so that
>> independent applications can both parse the same file with the same
>> semantics by obeying the file format specification, is a good design goal.
>
> We all know that documentation is rarely uptodate, new features may not
> get added and libvirt will never be able to keep up. The driver for a
> file format belongs in QEMU and nowhere else.
This would be possible if QEMU to provide a libblockformat.so library
which allowed apps to extract metadata from file formats using a stable
API.
How wrong would it be to call out to qemu-img to handle this instead?
Seems like a more stable interface (assuming the output of `qemu-img
info` is treated as an API of sorts, or perhaps some other output mode
is added to qemu-img that is considered stable).
Daniel