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