Re: Configuration vs. compat hints [was Re: [Qemu-devel] [PATCHv3 03/13] qemu: add routines to manage PCI capabilities]

[Michael S. Tsirkin]

On Mon, Jun 15, 2009 at 09:20:00AM -0500, Anthony Liguori wrote:
> Mark McLoughlin wrote:
>> On Mon, 2009-06-15 at 07:48 -0500, Anthony Liguori wrote:
>>   
>>>> 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.
>>   
>
> It doesn't have to be pc1, pc2.  It could be pc-with-usb or  
> pc-with-balloon.  If a distro cherry picks in such a way that their pc  
> is not a standard QEMU pc, they would add a new PC type that's specific  
> to their distro.
>
>> 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.
>>   
>
> Another option is an explicit -M default which always uses the default  
> machine for the architecture.  Likewise, we would need a way to query  
> what the default machine was for an architecture.
>
>> 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?
>>   
> You would introduce a new machine type.  For instance,  
> pc-virtio-class-other.  The names don't have to look like that, I'm just  
> doing that to make a point.  This may mean that you end up with dozens  
> of machine types but you preserve compatibility, which is a good thing.

And then pc-virtio-class-other-with-balloon-without-usb? Wouldn't it be
more straightforward to have capability bits which can be switched on
and off independently rather than trying to fit unrelated features into
a machine type?  IMO it only seems more work at first, and QA gets a bit
nervious that they can't exhaustively test all options. But in the long
run it simplifies things as you don't have to set policy and invent
silly names.

> Of course, the flip side is that you make preserving the machine config  
> the duty of the user and we don't maintain compatible machine types.   
> This won't work without a proper config file though so for now, we're  
> stuck maintaining machine types.
>
> Regards,
>
> Anthony Liguori