From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57453) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RW81C-0004n9-Ep for qemu-devel@nongnu.org; Thu, 01 Dec 2011 09:53:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RW810-0005jJ-VY for qemu-devel@nongnu.org; Thu, 01 Dec 2011 09:53:46 -0500 Received: from e7.ny.us.ibm.com ([32.97.182.137]:45573) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RW810-0005j0-T3 for qemu-devel@nongnu.org; Thu, 01 Dec 2011 09:53:34 -0500 Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 1 Dec 2011 09:53:33 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pB1ErOlK745576 for ; Thu, 1 Dec 2011 09:53:24 -0500 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pB1ErKqX027684 for ; Thu, 1 Dec 2011 07:53:20 -0700 Message-ID: <4ED794DF.8090800@us.ibm.com> Date: Thu, 01 Dec 2011 08:53:19 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1322687028-29714-1-git-send-email-aliguori@us.ibm.com> <1322687028-29714-8-git-send-email-aliguori@us.ibm.com> <4ED76325.6080305@redhat.com> <4ED784B3.8060800@codemonkey.ws> <4ED7892A.1050502@redhat.com> In-Reply-To: <4ED7892A.1050502@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 07/18] qom: add link properties List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Kevin Wolf , Peter Maydell , Stefan Hajnoczi , Jan Kiszka , qemu-devel@nongnu.org, Markus Armbruster , Luiz Capitulino On 12/01/2011 08:03 AM, Avi Kivity wrote: > On 12/01/2011 03:44 PM, Anthony Liguori wrote: >>> So, links are equivalent to pointers? >> >> >> Yup. Once we have qom inheritance (next stage), we can have a >> link property and you'll be able to set it to an E1000State >> with the appropriate casting and error checking taking place. > > I really like this goal but can't help feeling that we're stretching C > beyond its limits here, so that the client code ends up > boilerplate-heavy. Kind of like the issue with local_err elsewhere in > this thread, where you juggle things instead of a "throw > Exception(...)". I understand and have been down every possible road here. It's tempting to look at C++ or another language and view it as a simplifying assumption that makes the whole effort tremendously easier. But that's not been my experience. We just have to stretch C++ in different ways and you end up with that same icky feeling at the end of the day. > What does the client code looks like for link? I'm not sure what you mean by client code, but consider a device called UsbController that looks like: struct UsbController { DeviceState parent; UsbDevice *slave; // link property }; To add this as a link, somewhere in the init function you would do: static void usb_controller_initfn(UsbController *dev) { ... qdev_property_add_link(DEVICE(dev), "slave", "UsbDevice", (DeviceState **)&dev->slave, NULL); } If you want to set the property explicitly, you would just do: dev->slave = some_other_device You don't need to use any special function to manipulate the link. Stylistically, I'd prefer that all devices exposed accessor functions and that you did these things through accessors so that we had clear rules about what's public and private. In terms of QMP client code, you just do: qom-set /path/to/usb-controller.slave /some/other/device Regards, Anthony Liguori