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 -=|