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