From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MauDb-00049S-EG
	for qemu-devel@nongnu.org; Tue, 11 Aug 2009 12:28:59 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MauDW-00046C-4e
	for qemu-devel@nongnu.org; Tue, 11 Aug 2009 12:28:58 -0400
Received: from [199.232.76.173] (port=56739 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MauDV-000466-Jn
	for qemu-devel@nongnu.org; Tue, 11 Aug 2009 12:28:53 -0400
Received: from mx2.redhat.com ([66.187.237.31]:59396)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1MauDU-0004b2-Vi
	for qemu-devel@nongnu.org; Tue, 11 Aug 2009 12:28:53 -0400
Message-ID: <4A819C3E.7060106@redhat.com>
Date: Tue, 11 Aug 2009 18:28:46 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 4/4] qdev: add display capability
References: <1249982427-14481-1-git-send-email-kraxel@redhat.com>
	<1249982427-14481-4-git-send-email-kraxel@redhat.com>
	<4A81755F.3060600@codemonkey.ws> <4A817D73.4020200@redhat.com>
	<4A8194D9.9040202@codemonkey.ws>
In-Reply-To: <4A8194D9.9040202@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org

On 08/11/09 17:57, Anthony Liguori wrote:
> Gerd Hoffmann wrote:
>> That is the case for some devices only.
>
> A device doesn't have a capability unless it implements the backend
> device interface, no?

Right.  Although that doesn't imply there is a property needed for that.

>> What property do you use to identify display devices?
>
> A DisplayState * property (r/o).

Ok, that is the backend side of display devices.  It would somehow make 
sense to export that as property like we do today for DriveInfo and 
CharDriverState, although there is no need right now to have that 
accessable as property.


>> What property do you use to identify sound devices?
>
> A QEMUSoundCard * property (r/o).

That is a linked list of all sound card device instances.

>> What property do you use to identify watchdog devices?
>
> A WatchdogTimerModel * property (r/o).

That is a linked list of all watchdog device models.

Why on earth these should become device properties?
That doesn't make sense to me at all.

Oh, and the WatchdogTimerModel is the one I actually want to kill off 
some day (after converting watchdogs to qdev).  There is no need for a 
private device model list, we can use the qdev list instead and filter 
for DeviceInfo->caps & DEV_CAP_WATCHDOG.

cheers,
   Gerd