From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59296) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uulqf-0003jW-GV for qemu-devel@nongnu.org; Thu, 04 Jul 2013 11:53:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uulqe-0003br-JV for qemu-devel@nongnu.org; Thu, 04 Jul 2013 11:53:33 -0400 Received: from mail-lb0-f174.google.com ([209.85.217.174]:49190) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uulqe-0003bY-D6 for qemu-devel@nongnu.org; Thu, 04 Jul 2013 11:53:32 -0400 Received: by mail-lb0-f174.google.com with SMTP id x10so1346772lbi.19 for ; Thu, 04 Jul 2013 08:53:31 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <87zju2xs3i.fsf@blackfin.pond.sub.org> References: <1372943363-24081-1-git-send-email-armbru@redhat.com> <1372943363-24081-3-git-send-email-armbru@redhat.com> <87zju2xs3i.fsf@blackfin.pond.sub.org> From: Peter Maydell Date: Thu, 4 Jul 2013 16:53:11 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH 2/7] qemu-option: Fix qemu_opts_set_defaults() for corner cases List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Jan Kiszka , aliguori@us.ibm.com, qemu-devel@nongnu.org On 4 July 2013 16:28, Markus Armbruster wrote: > Peter Maydell 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