From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50205 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGaOL-0002IR-Da for qemu-devel@nongnu.org; Mon, 24 May 2010 12:20:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGaOF-0001H8-8V for qemu-devel@nongnu.org; Mon, 24 May 2010 12:20:33 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:40186) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGaOB-0001GY-Li for qemu-devel@nongnu.org; Mon, 24 May 2010 12:20:31 -0400 Message-ID: <4BFAA73F.9020101@web.de> Date: Mon, 24 May 2010 18:20:15 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4BFA9E8C.2070602@web.de> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7702B0E7220DE7AD7CF9CFD4" 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) --------------enig7702B0E7220DE7AD7CF9CFD4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Juan Quintela wrote: > Jan Kiszka wrote: >> Juan Quintela wrote: >=20 >> Unless this is deadly urgent, please hold it back until we sorted out >> some more fundamental issues with the HPET, specifically ported it to = qdev. >=20 > This series are independent of the qdev change (it almost don't change > hpet code at all). It is basically independent of almost everything el= se. It causes mechanical breakage to the qdev change (and the one I'm hacking on ATM). >=20 >> 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. >=20 > This happens to us all the time for lots of devices. And the big > problem is that there is no sane way to disable them :( >=20 > If we can agree in a mechanism to disable them (like this one) or > something similar, we could remove it. >=20 > Our biggest problem with shipping a device is that we are going to > support it for 7 years, you can guess why we want to be conservative. In this particular case, it is a one line patch: "no_hpet =3D 1;", hardwi= red. >=20 >> The >> HPET model is still incomplete in has some remaining quicks (hold on f= or >> 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. >=20 > Then, what should we do? Help fixing it (e.g. testers will soon be welcome). > We already have to disable hpet for 5.4 (1 year ago). It was done with= > a local hack because it was supposed that for next big release it would= > have been fixed. But this remains a RHEL issue. Redhat decided to compile out features that are unsupported, others seem to handle this differently. >=20 > Here we are, and device is still not fixed, what to do? Another local > patch? Just get upstream to integrate a sane way to disable it and let= > in enable by default? Let's start with listing your requirements to no longer disable HPET. That would already help us to asses how long !CONFIG_HPET would actually be of any use at all. I'm yet optimistic that we can resolve most if not all remaining concerns for 0.13 - and CONFIG_HPET would at best be 0.13 material anyway. >=20 > Notice that this patch was sent against hpet as one example, if we agre= e > that this "way" of disabling devices is ok, we could disable more > devices/have more flexibility. Notice that in general, we (RHEL/KVM) > are interested in a small subset of qemu devices. At least HPET is IMHO a bad example as it is, just like e.g. the IOAPIC, an essential part of today's x86 systems. Jan --------------enig7702B0E7220DE7AD7CF9CFD4 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 iEYEARECAAYFAkv6p0gACgkQitSsb3rl5xTY3QCeP86Nb1SJ0LqkkXv2TigS+Fu0 swwAn0l2cEKsx/uwTtYKe3qtnaLedBj9 =tKeH -----END PGP SIGNATURE----- --------------enig7702B0E7220DE7AD7CF9CFD4--