From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51801) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VRTrn-0001Cr-06 for qemu-devel@nongnu.org; Wed, 02 Oct 2013 17:22:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VRTre-0005lT-2r for qemu-devel@nongnu.org; Wed, 02 Oct 2013 17:21:54 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:51768) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VRTrd-0005lO-Sj for qemu-devel@nongnu.org; Wed, 02 Oct 2013 17:21:46 -0400 Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 2 Oct 2013 15:21:44 -0600 Received: from b01cxnp22036.gho.pok.ibm.com (b01cxnp22036.gho.pok.ibm.com [9.57.198.26]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 47E0C6E8048 for ; Wed, 2 Oct 2013 17:21:40 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by b01cxnp22036.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r92LLel237748738 for ; Wed, 2 Oct 2013 21:21:40 GMT Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r92LLbi3031752 for ; Wed, 2 Oct 2013 18:21:40 -0300 Message-ID: <524C8E5E.5040703@linux.vnet.ibm.com> Date: Wed, 02 Oct 2013 17:21:34 -0400 From: "Jason J. Herne" MIME-Version: 1.0 References: <1375366359-11553-1-git-send-email-jjherne@us.ibm.com> <1375366359-11553-6-git-send-email-jjherne@us.ibm.com> <522872B6.5080705@suse.de> <523B5C62.4050804@linux.vnet.ibm.com> In-Reply-To: <523B5C62.4050804@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 5/8] [PATCH RFC v3] s390-qemu: cpu hotplug - ipi_states enhancements Reply-To: jjherne@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: jjherne@linux.vnet.ibm.com Cc: ehabkost@redhat.com, qemu-devel@nongnu.org, agraf@suse.de, borntraeger@de.ibm.com, jfrei@linux.vnet.ibm.com, Anthony Liguori , Paolo Bonzini , imammedo@redhat.com, "Jason J. Herne" , =?ISO-8859-15?Q?Andreas_F=E4rber?= On 09/19/2013 04:19 PM, Jason J. Herne wrote: > On 09/05/2013 08:01 AM, Andreas Färber wrote: >> Am 01.08.2013 16:12, schrieb Jason J. Herne: >>> From: "Jason J. Herne" >>> > ... >> >> This is what got us into the link<> discussion last time. If we do >> >> for (i = 0; i < ARRAY_SIZE(ipi_states); i++) { >> name = g_strdup_printf("cpu[%i]", i); >> object_property_add_link(qdev_get_machine(), name, TYPE_S390_CPU, >> &ipi_states[i], &err); >> } >> >> then we get said /machine/cpu[n] link<> properties, at a QMP level >> either returning nothing or the canonical path to the CPU object. >> >> On IRC I didn't get an answer of whether it was being done the above way >> because there is infrastructure missing, and a look at object.h now >> confirms that suspicion. CC'ing Anthony and Paolo. >> >> Since object_property_add_link() uses a NULL opaque, my idea would be to >> add a single setter hook argument passed through as opaque to >> object_set_link_property(), which would call it with the old and the new >> value. >> >> The purpose would be to avoid growing our own internal setter API, which >> is disjoint from the QMP qom-set we are targetting at. > > I wrote the code, very close to how you suggested and it appears to be > working when tested with qom-list. I'm still not certain why we need > the ability to set the opaque of object_set_link_property()? > > For reference here is what I did: > > void s390_init_cpus(const char *cpu_model) > { > int i; > char* name; > > if (cpu_model == NULL) { > cpu_model = "host"; > } > > ipi_states = g_malloc0(sizeof(S390CPU *) * max_cpus); > > for (i = 0; i < max_cpus; i++) { > name = g_strdup_printf("cpu[%i]", i); > object_property_add_link(qdev_get_machine(), name, TYPE_S390_CPU, > (Object **)&ipi_states[i], NULL); > } > > for (i = 0; i < smp_cpus; i++) { > cpu_s390x_init(cpu_model); > } > } > > Yep, I know cpu_model is going away ;). > Ping? :) -- -- Jason J. Herne (jjherne@linux.vnet.ibm.com)