On Tue, Jul 19, 2011 at 3:30 PM, Jes Sorensen <Jes.Sorensen(a)redhat.com> 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.
It should be a goal to avoid dependencies in multiple layers of the
stack because it becomes are to add new features - they require
coordinated changes in multiple layers. Having both QEMU and libvirt
know the internals of image files is such a multi-dependency. If I
want to add a new format or change an existing format I have to touch
both layers.
For fd-passing perhaps we have an opportunity to use a callback
mechanism (QEMU request: filename -> libvirt response: fd) and do all
the image format parsing in QEMU.
Stefan