From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38020) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WgEqq-0003B1-HC for qemu-devel@nongnu.org; Fri, 02 May 2014 10:54:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WgEqk-0006hS-0d for qemu-devel@nongnu.org; Fri, 02 May 2014 10:54:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55259) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WgEqj-0006h7-OY for qemu-devel@nongnu.org; Fri, 02 May 2014 10:54:05 -0400 Message-ID: <5363B188.9090500@redhat.com> Date: Fri, 02 May 2014 16:54:00 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1398889773-14652-1-git-send-email-ehabkost@redhat.com> <20140502154503.72465f99@nial.usersys.redhat.com> <20140502144305.GJ3363@otherpad.lan.raisama.net> In-Reply-To: <20140502144305.GJ3363@otherpad.lan.raisama.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost , Igor Mammedov Cc: libvir-list@redhat.com, Jiri Denemark , Peter Krempa , qemu-devel@nongnu.org, =?ISO-8859-1?Q?Andreas_F=E4rber?= Il 02/05/2014 16:43, Eduardo Habkost ha scritto: > The first thing I considered was making icc-bus user-creatable. Then I > noticed it wouldn't work because object-add always add objects to > /objects, not inside the qdev hierarchy (that's where device_add looks > for the bus). > > So, allowing device_add could be possible, but would require changing > more basic infrastructure: either allowing bus-less devices on > device_add, or allowing device_add to add devices outside the qdev > hierarchy, or allowing object-add to create objects outside /objects. > > Simply making CPU objects work with object-add was much simpler and less > intrusive. And it had the interesting side-effect of _not_ doing things > that are not required for CPU model probing (like creating an actual > VCPU thread). I like this series in general. I have only some doubts about making the code somewhat future-proof, hence the three questions I have are really variations of this same doubt: * is it worthwhile to extend this to other devices, for management to query default values of the properties? * how does this interact with future QOMification of device hotplug where devices will be hotplugged with object-add? Should Device::UserCreatable::complete set realized to true in this case in the future? How will Device::UserCreatable::complete distinguish the two cases? * Related to this, if Device::UserCreatable::complete will set realized to true, how will we handle hotplug of interconnected devices where device 1 needs a link to device 2 and device 2 needs a link to device 1? Paolo