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

Michael S. Tsirkin
2009-06-15T14:36:25Z

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