Re: [Qemu-devel] [PATCH 2/7] qemu-option: Fix qemu_opts_set_defaults() for corner cases

[Peter Maydell]

On 4 July 2013 16:28, Markus Armbruster <address@hidden> wrote:
> Peter Maydell <address@hidden> writes:
>> On the other hand I don't think the old code's behaviour
>> was really right either. I think part of the problem here
>> is that it really makes no sense to specify id= for a
>> QemuOptsList with merge_lists=true -- id= is for distinguishing
>> which of multiple "-whatever id=foo,a=b -whatever id=bar,a=c"
>> sets you want, whereas merge_lists=true is specifying that
>> there should only ever be one set, because they're merged.
>
> Isn't interpreting merge_lists as "there can only be one" stretching it
> a bit?  All it clearly says to me is "merge multiple options with the
> same ID", and that's all the code does.
>
> Merging is merely a syntactic convenience.  Why is that convenience only
> justified for "there can only be one" options, such as -machine?

Well, I think if you have a "can be only one" option then
you might as well turn on merging (as you say it's a syntactic
convenience). If you have an option where id= is mandatory
then you could have merging enabled there; but we don't have
any of those. But for options where id= is allowed but not
mandatory then merging doesn't really work. You don't want
 -device e1000 -device megasas
to merge those two, for instance.

So it just seems like it cuts down the set of combinations
to divide it into:
 * can-be-only-one, merges
 * multiple-allowed, no merging

and I guess it's less confusing for users if there aren't
too many different combinations of behaviour.

> QemuOpts has become unmanagably baroque.

Agreed. This is partly why I'm suggesting cutting down
the possible random combinations (especially where we don't
actually use them).

thanks
-- PMM