On Thu, Aug 10, 2006 at 05:08:58AM -0400, Daniel Veillard wrote:
On Wed, Aug 09, 2006 at 09:33:11PM -0400, Jeremy Katz wrote:
> On Thu, 2006-08-10 at 01:00 +0100, Daniel P. Berrange wrote:
> > I meant to include a complete example XML doc showing the changes in
> > place, so here is a XML dump from a HVM domain which has been booted
> > off a CDROM:
> [snip]
> > <disk type='file'>
> > <source file='/root/foo.img'/>
> > <target dev='ioemu:hda'/>
> > </disk>
>
> Given what we know is coming, does it make sense to drop the ioemu: here
> and just have it be implied for HVM guests? Accept it if it's there
> (and then drop it if we're on xend 3.0.3), but not really show it?
Sound sensible, the problem is detecting the version of xend,
of course you can ask xend, you will get the exact version of the
compiler used to compile it, but when it comes to xen version itself
(xen_major 3) (xen_minor 0) (xen_extra -unstable)
which makes things a bit hard to distinguish 3.0.2 from 3.0.3 :-\
Basically trying to hook off version number is not ever really going
to be reliable because we need libvirt to be able to work against
development snapshots - features may be introduced during dev that need
detecting before the version number is incremented.
We could try to use the changest but it's not available in our
build
either.
Hooking off changeset looks & smells like a nasty hack.
What is really needed is a version number for the SEXPR format returned
by XenD. A simple incrementing integer digit would suffice really.
(xen_sexpr_format 4)
Which could be incremented each time a new capability is introduced,or
an existing one changed. Something to propose upstream asap ?
Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules:
http://search.cpan.org/~danberr/ -=|
|=- Projects:
http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|