From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MWBko-0008T0-1m for qemu-devel@nongnu.org; Wed, 29 Jul 2009 12:11:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MWBkj-0008Kj-Id for qemu-devel@nongnu.org; Wed, 29 Jul 2009 12:11:45 -0400 Received: from [199.232.76.173] (port=48282 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MWBkj-0008KY-7u for qemu-devel@nongnu.org; Wed, 29 Jul 2009 12:11:41 -0400 Received: from mx2.redhat.com ([66.187.237.31]:39509) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MWBki-0003bc-KU for qemu-devel@nongnu.org; Wed, 29 Jul 2009 12:11:41 -0400 Date: Wed, 29 Jul 2009 13:11:31 -0300 From: Luiz Capitulino Message-ID: <20090729131131.2d5e4fa6@doriath> In-Reply-To: <4A705EAB.1030200@redhat.com> References: <1248818713-11261-1-git-send-email-lcapitulino@redhat.com> <1248818713-11261-2-git-send-email-lcapitulino@redhat.com> <4A701AA3.4060902@redhat.com> <20090729104600.17deb355@doriath> <4A705536.3020305@redhat.com> <20090729112220.16ffe414@doriath> <4A705EAB.1030200@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 01/25] Introduce QEMU dictionary data type List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: jan.kiszka@siemens.com, aliguori@us.ibm.com, dlaor@redhat.com, qemu-devel@nongnu.org On Wed, 29 Jul 2009 17:37:31 +0300 Avi Kivity wrote: > On 07/29/2009 05:22 PM, Luiz Capitulino wrote: > > > > > >> I meant QObject as a base type, so it is a lower layer than QDict; QDict > >> implements the QObject methods, as do QString, QNumber, etc. > >> > > > > Ok, I'm failing at imagining "QDict implements the QObject methods" > > in C, can you elaborate more and/or sketch something? > > > > It's really no different than in other languages, except that you have > to write a ton of boilerplate. The kernel is riddled with object > hierarchies: > > typedef struct QType { > const char *name; > void (*destroy)(QObject *); > QObject *(*clone)(QObject *) > } QType; > > typedef struct QObject { > QType *type; > } QObject; > > typedef struct QDict { > QObject base; > // hash stuff > } QDict; > > static QType qdict_type = { > .destroy = qdict_destroy, > .clone = qdict_clone, > }; > > QObject *qobject_clone(QObject *obj) { return obj->type->clone(obj); } > > QObject *qdict_clone(QObject *obj) > { > ... > } Okay, this is really far away from what I had in my mind, will start working on this then. Thanks a lot for the explanation. > >> The problem with void *, beyond requiring the user to know what the > >> object type is, is that it is impossible to control object lifecycle. > >> When you destroy a QDict containing void *, you cannot destroy the > >> contained objects. On the other hand if QDict values are all QObjects, > >> then qdict_destroy() can call qobject_destroy() on all of them > >> (qobject_destroy might end up calling qdict_destroy() is a value > >> happened to be a QDict). > >> > > > > Right, but as you said in other email, can we get this merged first > > and then improve or should I do the change for this series? > > > > I think we should merge first, doing this sort of change on a 25-patch > series is no fun. Thanks a lot again. :) Btw, the patches that ports command handlers have some void * to long type conversions (eg. patch 14) can someone please review them? I'm not 100% confident about them.