From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40564) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmG0a-00072i-7B for qemu-devel@nongnu.org; Wed, 14 Oct 2015 02:58:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZmG0X-0008M1-0R for qemu-devel@nongnu.org; Wed, 14 Oct 2015 02:57:56 -0400 Received: from mailout1.w1.samsung.com ([210.118.77.11]:36184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmG0W-0008Le-QM for qemu-devel@nongnu.org; Wed, 14 Oct 2015 02:57:52 -0400 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout1.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NW7001T17CE4X30@mailout1.w1.samsung.com> for qemu-devel@nongnu.org; Wed, 14 Oct 2015 07:57:50 +0100 (BST) From: Pavel Fedin References: <1444739866-14798-1-git-send-email-berrange@redhat.com> In-reply-to: <1444739866-14798-1-git-send-email-berrange@redhat.com> Date: Wed, 14 Oct 2015 09:57:48 +0300 Message-id: <00bd01d1064d$a3c266d0$eb473470$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Content-language: ru Subject: Re: [Qemu-devel] [PATCH v4 0/7] qom: more efficient object property handling List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "'Daniel P. Berrange'" , qemu-devel@nongnu.org Cc: 'Paolo Bonzini' , 'Markus Armbruster' , =?utf-8?Q?'Andreas_F=C3=A4rber'?= Hello! > This series introduces a concept of object property iterators > to QOM so callers are insulated from the specific data structures > used for storing properties against objects/classes. It then > converts Object to use a GHashTable for storing properties. > Finally it introduces ObjectClass properties. Tested-by: Pavel Fedin =20 > Probably the only controversial thing is the item Pavel points > out about object_child_foreach iterators now being forbidden > from modifying the object composition tree. As i already wrote, current code does not modify the tree. If = necessary, it is possible to work around (e. g. make a decision about = modification, stop iteration, then do the modification). I think this = would pop up anyway if we change list to anything else. IMHO it's better = just to acknowledge that we should not modify our tree inside iterator. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia