From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=32829 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OKACj-0000t6-Fl for qemu-devel@nongnu.org; Thu, 03 Jun 2010 09:11:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OKACi-0007wm-2R for qemu-devel@nongnu.org; Thu, 03 Jun 2010 09:11:25 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:41347) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OKACh-0007wC-Uu for qemu-devel@nongnu.org; Thu, 03 Jun 2010 09:11:24 -0400 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o53D0IMs019089 for ; Thu, 3 Jun 2010 09:00:18 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o53DBK4r081144 for ; Thu, 3 Jun 2010 09:11:20 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o53DBKsl022801 for ; Thu, 3 Jun 2010 09:11:20 -0400 Message-ID: <4C07A9F6.9060200@linux.vnet.ibm.com> Date: Thu, 03 Jun 2010 08:11:18 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1275414976-18258-1-git-send-email-glommer@redhat.com> <1275414976-18258-2-git-send-email-glommer@redhat.com> <1275414976-18258-3-git-send-email-glommer@redhat.com> <4C0604FE.8070402@web.de> <20100602140608.GP19104@mothafucka.localdomain> <4C074689.6080106@web.de> In-Reply-To: <4C074689.6080106@web.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH v2 2/2] basic machine opts framework List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Glauber Costa , qemu-devel@nongnu.org On 06/03/2010 01:07 AM, Jan Kiszka wrote: > Glauber Costa wrote: > >> On Wed, Jun 02, 2010 at 09:15:10AM +0200, Jan Kiszka wrote: >> >>>> >>>> +QemuOptsList qemu_machine_opts = { >>>> + .name = "M", >>>> + .head = QTAILQ_HEAD_INITIALIZER(qemu_machine_opts.head), >>>> + .desc = { >>>> + { >>>> + .name = "mach", >>>> + .type = QEMU_OPT_STRING, >>>> + },{ >>>> + .name = "irqchip", >>>> + .type = QEMU_OPT_STRING, >>>> + }, >>>> >>> Can't we make the concrete machine define what options it needs? Pushing >>> this into the generic code may soon end up in a bunch of very special >>> switches that are unused on most machines or even have no meaning for them. >>> >>> Also, I would suggest to introduce the generic part first, and then add >>> first users like the x86 irqchip. >>> >> Yeah, in general, I do agree with you. >> >> Me and anthony talked about it for a while some time ago, and more or less >> concluded that it could be possible to avoid that, putting a little think >> which options to add. >> >> the "irqchip" option, if you note, is not x86-specific, in any case. >> Any machine has an irqchip. >> > ...but the majority has no choice among different models. This option > simply makes only sense for x86 now and in the foreseeable future. > > >> The first idea was to use something like >> "apic=in_kernel|userspace" which would be, that, very x86-centric. >> >> So, since letting machines define their own options adds complexity, >> my take would be to add those common options, and add infrastructure >> for machine-specific options when we see something that makes it >> unavoidable. >> >> What do you think? >> >> > I have no general concerns if you document irqchip as a x86-only machine > option without effect on other machines and you promise to clean this up > once done with in-kernel irqchip support (which is clearly more > important). But the current design should not stay that way for a longer > period to avoid what I sketched above. > What I think we need to do is actually use an empty QemuOptsList for the -machine option, make sure that the driver is present, then re-validate the list with a QemuOptsList that's included in the machine state. We should, of course, have a #define of MACHINE_COMMON_OPTS. This would allow machine specific options (like irqchip). I don't think irqchip is the best name really. I think it should be apic=kernel|user. Regards, Anthony Liguori > Jan >