From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:43126)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1UIFk8-00069W-8C
	for qemu-devel@nongnu.org; Wed, 20 Mar 2013 05:55:37 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1UIFk6-0002En-Lw
	for qemu-devel@nongnu.org; Wed, 20 Mar 2013 05:55:36 -0400
Received: from mx1.redhat.com ([209.132.183.28]:29028)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1UIFk6-0002EU-ED
	for qemu-devel@nongnu.org; Wed, 20 Mar 2013 05:55:34 -0400
Received: from int-mx09.intmail.prod.int.phx2.redhat.com
	(int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r2K9tXoF012004
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <qemu-devel@nongnu.org>; Wed, 20 Mar 2013 05:55:33 -0400
Received: from rincewind.home.kraxel.org (ovpn-116-26.ams2.redhat.com
	[10.36.116.26])
	by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
	id r2K9tWo5023514
	for <qemu-devel@nongnu.org>; Wed, 20 Mar 2013 05:55:33 -0400
Message-ID: <51498793.2000209@redhat.com>
Date: Wed, 20 Mar 2013 10:55:31 +0100
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] QOM-ify QemuConsoles ...
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: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>

  Hi,

So, the big qemu console data structure overhauls is done, patches just
posted to the list.

I think the next logical step ahead is to QOM-ify the QemuConsoles, so
we can link the QemuConsole to the thing actually backing it.  For a
graphical console that would be the emlated graphic device.  For a text
console it would be the serial line or monitor hooked up to it.

With this in place we should be able to answer questions like "which
device backs this QemuConsole" by inspecting the object tree and handle
requests like "do a screendump of this device please".  It will also be
useful to setup input routing: "pointer events from $this QemuConsole
should to $that virtual input device".

Hints how to do that best?  Pointers to sample code to look at?  From a
brief look it seems we only QOM-ified emulated devices and not host-side
objects yet ...

thanks,
  Gerd