From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:39644)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <andreas.faerber@web.de>) id 1Raktd-0002v1-O7
	for qemu-devel@nongnu.org; Wed, 14 Dec 2011 04:13:09 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <andreas.faerber@web.de>) id 1Raktb-000548-6w
	for qemu-devel@nongnu.org; Wed, 14 Dec 2011 04:13:05 -0500
Received: from mout.web.de ([212.227.15.4]:52389)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <andreas.faerber@web.de>) id 1Rakta-00053x-SZ
	for qemu-devel@nongnu.org; Wed, 14 Dec 2011 04:13:03 -0500
Message-ID: <4EE86832.2080006@web.de>
Date: Wed, 14 Dec 2011 10:11:14 +0100
From: =?ISO-8859-1?Q?Andreas_F=E4rber?= <andreas.faerber@web.de>
MIME-Version: 1.0
References: <4E70EC90.8000904@us.ibm.com>	<201112131740.29225.paul@codesourcery.com>	<4EE792D1.4020704@codemonkey.ws>
	<201112132036.01441.paul@codesourcery.com>
	<4EE7C955.5000101@codemonkey.ws>
In-Reply-To: <4EE7C955.5000101@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [Qemu-devel] [RFC] Plan for moving forward with QOM
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Peter Maydell <peter.maydell@linaro.org>, Jan Kiszka <jan.kiszka@siemens.com>, qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>, =?ISO-8859-1?Q?Herv=E9_Poussineau?= <hpoussin@reactos.org>, Gerd Hoffmann <kraxel@redhat.com>, "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, Paul Brook <paul@codesourcery.com>

Am 13.12.2011 22:53, schrieb Anthony Liguori:
> ISADevice could very easily become an Interface as it has no
> state today.

Not in upstream, but Hervé and me had been working on that for PReP, as
you may recall.

There seemed to be consensus that some ISA devices can choose which I/O
ports and IRQs to listen on (EEPROM state).

Further, since we disallow hotplug on ISA, enabled/disabled became
another ISADevice-internal state (ugly IMO and that's where we stalled).

The latter might be avoided by using pc87312 Super I/O has-a UART and by
not pretending they are ISADevices on a global ISABus but something
custom, private to Super I/O (which has enabled/disabled state in its
registers), that happen to look-and-feel just like ISA devices?

Andreas