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

Anthony Liguori
2009-06-12T14:51:10Z

Mark McLoughlin wrote:
> On Wed, 2009-06-10 at 20:27 +0100, Jamie Lokier wrote:
>
>> Michael S. Tsirkin wrote:
>>
>>>> I think the right long term answer to all this is a way to get QEMU to
>>>> dump it's current machine configuration in glorious detail as a file
>>>> which can be reloaded as a machine configuration.
>>>>
>>> And then we'll have the same set of problems there.
>>>
>> We will, and the solution will be the same: options to create devices
>> as they were in older versions of QEMU. It only needs to cover device
>> features which matter to guests, not every bug fix.
>>
>> However with a machine configuration which is generated by QEMU,
>> there's less worry about proliferation of obscure options, compared
>> with the command line. You don't necessarily have to document every
>> backward-compatibility option in any detail, you just have to make
>> sure it's written and read properly, which is much the same thing as
>> the snapshot code does.
>>
>
> This is a sensible plan, but I don't think we should mix these compat
> options in with the VM manager supplied configuration.
>
> There are two problems with that approach.
>
> = Problem 1 - VM manager needs to parse qemu config =
>
> Your proposal implies:
>
> - VM manager supplies a basic configuration to qemu
>
> - It then immediately asks qemu for a dump of the machine
> configuration in all its glorious detail and retains that
> config
>
> - If the VM manager wishes to add a new device it needs to parse the
> qemu config and add it, rather than just generate an entirely new
> config
>

What's the problem with parsing the device config and modifying it? Is
it just complexity?

If we provided a mechanism to simplify manipulating a device config,
would that eliminate the concern here?

Regards,

Anthony Liguori