From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48444 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGZoD-0004S8-EO for qemu-devel@nongnu.org; Mon, 24 May 2010 11:43:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGZoB-0003dU-7p for qemu-devel@nongnu.org; Mon, 24 May 2010 11:43:17 -0400 Received: from fmmailgate01.web.de ([217.72.192.221]:46122) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGZoA-0003dL-Ob for qemu-devel@nongnu.org; Mon, 24 May 2010 11:43:15 -0400 Message-ID: <4BFA9E8C.2070602@web.de> Date: Mon, 24 May 2010 17:43:08 +0200 From: Jan Kiszka MIME-Version: 1.0 References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF647DC6C19BACDFB1A077B09" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH 0/6] Make hpet a compile time option List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: Blue Swirl , qemu-devel@nongnu.org, Paul Brook This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF647DC6C19BACDFB1A077B09 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Juan Quintela wrote: > Hi >=20 > This series: > a- bring back the support for config-devices.h >=20 > Paul was the one that removed my previous submission. > You can see on the last patch why I want config-devices.h >=20 > b- move all hpet code to hpet.c/hpet_emul.h >=20 > In the last patch, I add CONFIG_HPET define, and made everything > depending on that define. When we have !CONFIG_HPET we just create > stub functions. >=20 > This was my idea to create config-devices.h in the first place. >=20 > Paul, if you don't like it, I am open to alternatives. Problem here > is that there are devices that we don't want to ship in RHEL for one > reason or another. Solutions so far: >=20 > - use Makefile/ifdefs in calling files trickery: this is ugly as hell > and was refused (I sent patches to do that ~1 year ago). >=20 > I was told to use CONFIG_FOO to disable the full compilation and a > config file, like the kernel. >=20 > Here we go, then Paul removed the config-device.h part, because: >=20 >> Also remove config-devices.h. Code does not and should not care whi= ch >> devices are being built. >=20 > This is ok, when device is only called through qdev, and then it is tri= vial > to compile out. >=20 > Notice that that there are another cases where we have to do Makefile t= ricks > just because we don't have config-devices.mak symbols in "C-land". >=20 > See for example Makefile.target >=20 > CONFIG_NO_KVM =3D $(if $(subst n,,$(CONFIG_KVM)),n,y) >=20 > obj-$(CONFIG_KVM) +=3D kvm.o kvm-all.o > obj-$(CONFIG_NO_KVM) +=3D kvm-stub.o >=20 > In this case makes sense to have an stub because there are lots of > functions, but in the hpet case there are only two functions that are > exported. My problem with the "stub file" way is that we are going to > end with three files by device (foo.c, foo-stub.c, foo.h). Where > foo-stub.c is basically trivial. >=20 > I also removed the "info hpet" command. I can be convinced that it is = better to change its > output to > HPET is disabled by QEMU > or > HPET is not present > or any other stirng. >=20 > Comments? Any better suggestion? Unless this is deadly urgent, please hold it back until we sorted out some more fundamental issues with the HPET, specifically ported it to qde= v. But I'm also not convinced about the general approach. Except for RHEL packagers, no one seems to gain any benefit from having CONFIG_HPET. The HPET model is still incomplete in has some remaining quicks (hold on for improvements), but that doesn't qualify it for !CONFIG_HPET, specifically as it is deeply hooked into every modern PC. If I was asked, I guess I would nack this switch. Jan --------------enigF647DC6C19BACDFB1A077B09 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 iEYEARECAAYFAkv6npAACgkQitSsb3rl5xTjbACgxt7oHI9vkCWB01aPaWZbPk9e XlwAn3B33TriGhZjHNdKV7S1LoBIpxHT =P/7S -----END PGP SIGNATURE----- --------------enigF647DC6C19BACDFB1A077B09--