From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49019) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXYhL-0005bP-62 for qemu-devel@nongnu.org; Thu, 24 May 2012 10:07:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SXYhB-0004GO-8y for qemu-devel@nongnu.org; Thu, 24 May 2012 10:07:26 -0400 Received: from mail-ob0-f173.google.com ([209.85.214.173]:57639) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SXYhB-0004Fa-4B for qemu-devel@nongnu.org; Thu, 24 May 2012 10:07:17 -0400 Received: by obbwd20 with SMTP id wd20so15582779obb.4 for ; Thu, 24 May 2012 07:07:15 -0700 (PDT) Message-ID: <4FBE4090.6080907@codemonkey.ws> Date: Thu, 24 May 2012 09:07:12 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1337859784-24097-1-git-send-email-armbru@redhat.com> <1337859784-24097-3-git-send-email-armbru@redhat.com> <4FBE31CD.1080101@codemonkey.ws> <4FBE3C38.8040401@redhat.com> <4FBE3F24.9010301@suse.de> In-Reply-To: <4FBE3F24.9010301@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH RFC 2/2] qmp: New command qom-new List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: qemu-devel@nongnu.org, Igor Mammedov , Markus Armbruster , pbonzini@redhat.com On 05/24/2012 09:01 AM, Andreas Färber wrote: > Am 24.05.2012 15:48, schrieb Igor Mammedov: >> On 05/24/2012 03:04 PM, Anthony Liguori wrote: >>> >>> I'm not sure how I feel about this. I never intended for a user to be >>> able to create objects that were arbitrary children of other objects. >>> >>> In some ways, I think this is almost too powerful of an interface to >>> expose to users. I like things like device_add() better that only >>> creates objects >>> of TYPE_DEVICE that are always in /peripherial. >>> >>> For block, we'd have a similar interface that always created objects >>> of TYPE_BLOCK_DRIVER and put them in /block. >> >> Will we have a special cases for every incompatible device types that is >> going to be hot-plugged via device_add monitor command? >> >> For CPUs my thoughts were moving in opposite direction, like: >> - make possible to create and initialize CPU as a regular QOM object >> - hack qdev_device_add() to allow not only TYPE_DEVICE to be created there >> >> There are patches out there that make cpu a child of /machine at board >> level. >> But for hot-added objects parent could be specified as a property >> or knowledge about parent hard-coded inside of object itself or >> hard-coded in device_add(). >> Which one of them likely to be adopted? > > For system emulation I am working towards making the CPU a device so > that we can reuse common device infrastructure: Ah, perfect, I guess great minds think alike :-) Regards, Anthony Liguori