From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37962) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbYQ9-0001YP-MM for qemu-devel@nongnu.org; Fri, 16 Dec 2011 09:06:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbYQ4-00042Y-22 for qemu-devel@nongnu.org; Fri, 16 Dec 2011 09:05:57 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:44520) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbYQ3-00042U-U1 for qemu-devel@nongnu.org; Fri, 16 Dec 2011 09:05:52 -0500 Received: by iagj37 with SMTP id j37so5030001iag.4 for ; Fri, 16 Dec 2011 06:05:51 -0800 (PST) Message-ID: <4EEB503A.5030706@codemonkey.ws> Date: Fri, 16 Dec 2011 08:05:46 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1324036918-2405-1-git-send-email-pbonzini@redhat.com> <1324036918-2405-7-git-send-email-pbonzini@redhat.com> <4EEB439F.7010601@redhat.com> <4EEB4CD2.8080907@redhat.com> In-Reply-To: <4EEB4CD2.8080907@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 6/8] qom: introduce get/set methods for Property List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: kwolf@redhat.com, Gerd Hoffmann , qemu-devel@nongnu.org On 12/16/2011 07:51 AM, Paolo Bonzini wrote: > On 12/16/2011 02:11 PM, Gerd Hoffmann wrote: >> I think we should not touch these. First it doesn't buy us much as we >> are using the old parse/print functions for the visitor-based access, >> which doesn't look like a good idea to me. Also they will not stay but >> will be converted to child<> and link<>, so I think it is better to keep >> the old stuff in the legacy<> namespace. > > I thought the same initially. However, I noticed that the visitor interfaces for > links is also a string. So, even if a block/char/netdev property later becomes a > link<>, the interface would not change. The semantics change though. A "drive" link takes a flat block device name. When it's converted to a link, it will take a QOM path. Since block devices will exist in their own directory, it will certainly still be possible to use the flat block device name but since a paths will also be supported, I think it's best to clearly distinguish the link based property from the flat block device name property. Regards, Anthony Liguori > > Paolo >