From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NYLit-0002gC-QO for qemu-devel@nongnu.org; Fri, 22 Jan 2010 10:46:59 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NYLip-0002fP-Pi for qemu-devel@nongnu.org; Fri, 22 Jan 2010 10:46:59 -0500 Received: from [199.232.76.173] (port=33141 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NYLip-0002fL-MG for qemu-devel@nongnu.org; Fri, 22 Jan 2010 10:46:55 -0500 Received: from e33.co.us.ibm.com ([32.97.110.151]:37888) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NYLio-0007DF-PK for qemu-devel@nongnu.org; Fri, 22 Jan 2010 10:46:55 -0500 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o0MFhcaX027718 for ; Fri, 22 Jan 2010 08:43:38 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id o0MFkjLC246638 for ; Fri, 22 Jan 2010 08:46:46 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o0MFjfCg010801 for ; Fri, 22 Jan 2010 08:45:41 -0700 Message-ID: <4B59C820.1070907@linux.vnet.ibm.com> Date: Fri, 22 Jan 2010 09:45:36 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 3/4] Add -defaults option to allow default devices to be overridden References: <1264099733-29666-1-git-send-email-aliguori@us.ibm.com> <1264099733-29666-4-git-send-email-aliguori@us.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: John Cooper , qemu-devel@nongnu.org, Gerd Hoffman On 01/22/2010 04:15 AM, Markus Armbruster wrote: > Anthony Liguori writes: > > >> This option can be used to toggle whether each default device is enabled or >> disabled. For character devices, the default backend can also be overridden. >> >> For devices, we'll have to take a different approach to changing the defaults >> which will be covered in the next patch. >> >> N.B. I took special care with -nographic. Now -nographic pretty clearly acts >> as a mechanism to override the default backend devices. >> >> Signed-off-by: Anthony Liguori >> --- >> qemu-config.c | 45 +++++++++++++++++++++++++++++++++ >> qemu-config.h | 1 + >> qemu-options.hx | 7 +++++ >> vl.c | 75 +++++++++++++++++++++++++++++++++++++++++-------------- >> 4 files changed, 109 insertions(+), 19 deletions(-) >> >> diff --git a/qemu-config.c b/qemu-config.c >> index c3203c8..82ca399 100644 >> --- a/qemu-config.c >> +++ b/qemu-config.c >> @@ -242,6 +242,50 @@ QemuOptsList qemu_mon_opts = { >> }, >> }; >> >> +QemuOptsList qemu_default_opts = { >> + .name = "default", >> + .head = QTAILQ_HEAD_INITIALIZER(qemu_default_opts.head), >> + .desc = { >> + { >> + .name = "serial", >> + .type = QEMU_OPT_STRING, >> + }, >> > [...] > >> diff --git a/qemu-options.hx b/qemu-options.hx >> index 57f453d..e81ecb5 100644 >> --- a/qemu-options.hx >> +++ b/qemu-options.hx >> @@ -1919,6 +1919,13 @@ STEXI >> Don't create default devices. >> ETEXI >> >> +DEF("default", HAS_ARG, QEMU_OPTION_default, \ >> + "-default arg specify default devices\n") >> > Isn't this too terse? > Yes. Thanks for pointing that out. >> +STEXI >> +@item -defaults >> +Override builtin default devices >> +ETEXI >> > This *is* too terse :) > > Oh, and it's -default (sans 's'). Same typo in subject. > > While we're talking about naming: isn't -default a bit too generic a > name for something that manipulates devices? Not sure we care, as > -nodefaults is much worse, already. > Absolutely. I'm going to split out the config loading bits because they should be easy to commit. How to best handle defaults could use some more thought. I think this is a key bit of functionality to get right though because it solves a whole class of problems relating to upstream policy vs. downstream policy. I very much like the idea of having a qdev property 'default' to signify that this is a default device. It means we could easily allow a user to universally enable usb devices, etc without baking a default_usb concept into qemu. Ideally, we could eliminate the whole default mess we have today by doing this, provided that we can implement the right semantics. Today, those semantics are, if we specify any device of the same "class", do not load default devices of that class. It's unclear how to specify the concept of a "class" though. I know Gerd brought this up ages ago and both Paul and I were very opposed to it but I certainly appreciate the fact that it would simplify default device handling. It's definitely clear that each device needs to be able to be part of multiple default-class's. We could potentially introduce a qdev property and label every device with a class array but that's a lot of ugliness just to support defaults. I still would prefer that there was a more discoverable way to determine the class of a device as opposed to explicitly labelling it. If we need to do class tagging, I guess it's not the end of the world... Regards, Anthony Liguori > [...] >