qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13]


From: Mark McLoughlin
Subject: Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities]
Date: Mon, 15 Jun 2009 15:00:47 +0100

On Mon, 2009-06-15 at 07:48 -0500, Anthony Liguori wrote:
> Avi Kivity wrote:
> > On 06/15/2009 12:09 PM, Mark McLoughlin wrote:
> >>>>> I think the point is that you don't need version numbers if you 
> >>>>> have a
> >>>>> proper device tree.
> >>>>>
> >>>>>          
> >>>> How do you add a new attribute to the device tree and, when a supplied
> >>>> device tree lacking said attribute, distinguish between a device tree
> >>>> from an old version of qemu (i.e. use the old default) and a partial
> >>>> device tree from the VM manager (i.e. use the new default) ?
> >>>>
> >>>>        
> >>> -baseline 0.10
> >>>      
> >>
> >> That's a version number :-)
> >>
> >> (I was responding to Anthony's "you don't need a version number")
> >>    
> >
> > If you want to prevent incompatibilities, you need to make everything 
> > new (potentially including bugfixes) non-default.

No need to punish new guests in order to maintain compatibility for old
guests.

> > Eventually the 
> > default configuration becomes increasingly unusable and you need a new 
> > baseline.  You must still be able to fall back to the old baseline for 
> > older guests.  I don't think games with configuration files can hide 
> > that.
> 
> -M pc1
> -M pc2
> 
> etc.
> 
> This is pretty easy to maintain with config files.

I think this would be reasonable, but it is essentially just a version
number which you objected to on the basis that it would make
cherry-picking harder for distros.

One thing that would be nice with this '-M pc1' thing would be to retain
'-M pc' as a symlink to the latest version. We'd also need a way to read
the symlink too, so that you can query what the current latest version
is and use that in future.

How would this machine type version relate to e.g. changing the default
PCI class of virtio-blk? Would we bump the version number of all machine
types can use virtio-blk?

A per-device version number is workable alternative, but only with a
saveabi type file IMHO.

I've tried to summarise the options here:

  https://fedoraproject.org/wiki/Features/KVM_Stable_Guest_ABI

Cheers,
Mark.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]