On 4 July 2013 16:28, Markus Armbruster <arm...@redhat.com> wrote: > Peter Maydell <peter.mayd...@linaro.org> 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
