From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44818 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OK3aA-00044x-1f for qemu-devel@nongnu.org; Thu, 03 Jun 2010 02:07:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OK3a8-0001cV-Ab for qemu-devel@nongnu.org; Thu, 03 Jun 2010 02:07:09 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:54556) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OK3a7-0001cF-VA for qemu-devel@nongnu.org; Thu, 03 Jun 2010 02:07:08 -0400 Message-ID: <4C074689.6080106@web.de> Date: Thu, 03 Jun 2010 08:07:05 +0200 From: Jan Kiszka 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> In-Reply-To: <20100602140608.GP19104@mothafucka.localdomain> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBEA48D36062F51887FD8CB8C" Sender: jan.kiszka@web.de 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: Glauber Costa Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBEA48D36062F51887FD8CB8C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Glauber Costa wrote: > On Wed, Jun 02, 2010 at 09:15:10AM +0200, Jan Kiszka wrote: >>> =20 >>> +QemuOptsList qemu_machine_opts =3D { >>> + .name =3D "M", >>> + .head =3D QTAILQ_HEAD_INITIALIZER(qemu_machine_opts.head), >>> + .desc =3D { >>> + { >>> + .name =3D "mach", >>> + .type =3D QEMU_OPT_STRING, >>> + },{ >>> + .name =3D "irqchip", >>> + .type =3D QEMU_OPT_STRING, >>> + }, >> Can't we make the concrete machine define what options it needs? Pushi= ng >> 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 ad= d >> first users like the x86 irqchip. > Yeah, in general, I do agree with you. >=20 > Me and anthony talked about it for a while some time ago, and more or l= ess > concluded that it could be possible to avoid that, putting a little thi= nk > which options to add. >=20 > the "irqchip" option, if you note, is not x86-specific, in any case. > Any machine has an irqchip. =2E..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=3Din_kernel|userspace" which would be, that, very x86-centric. >=20 > 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. >=20 > What do you think?=20 >=20 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. Jan --------------enigBEA48D36062F51887FD8CB8C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkwHRooACgkQitSsb3rl5xRbLQCgggEHW2pUVFNe0CZBvqI/Vjg1 GywAoK+EhfjkWj4P/y7Ic75e0697oLJ/ =7BB5 -----END PGP SIGNATURE----- --------------enigBEA48D36062F51887FD8CB8C--