From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33491) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXUcD-0005NZ-I0 for qemu-devel@nongnu.org; Mon, 05 Dec 2011 04:13:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RXUcC-0003mn-FT for qemu-devel@nongnu.org; Mon, 05 Dec 2011 04:13:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33118) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RXUcC-0003lu-7t for qemu-devel@nongnu.org; Mon, 05 Dec 2011 04:13:36 -0500 Message-ID: <4EDC8BE7.1000402@redhat.com> Date: Mon, 05 Dec 2011 10:16:23 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <1322687028-29714-1-git-send-email-aliguori@us.ibm.com> <1322687028-29714-2-git-send-email-aliguori@us.ibm.com> <4ED7A2A1.80002@redhat.com> <4ED91D2E.4050308@codemonkey.ws> In-Reply-To: <4ED91D2E.4050308@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 01/18] qom: add new dynamic property infrastructure based on Visitors List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Maydell , Stefan Hajnoczi , Markus Armbruster , qemu-devel@nongnu.org, Luiz Capitulino , Jan Kiszka Am 02.12.2011 19:47, schrieb Anthony Liguori: > On 12/01/2011 09:52 AM, Kevin Wolf wrote: >> Am 30.11.2011 22:03, schrieb Anthony Liguori: >>> + >>> +void qdev_property_add(DeviceState *dev, const char *name, const char *type, >>> + DevicePropertyEtter *get, DevicePropertyEtter *set, >>> + DevicePropertyRelease *release, void *opaque, >>> + Error **errp) >> >> How about letting the caller pass in a DeviceProperty for improved >> readability and usability? Instead of memorizing the order of currently >> eight parameters (could probably become more in the future) you can use >> proper C99 initializers then. > > This ends up making the code much more complex for the client if you try to > eliminate the opaque and replace it with the structure. It becomes necessary to > do a dynamic allocation of the structure and then you also have to add a release > function. Hm, why doesn't static allocation work with it? > We could make the structure just contain the function pointers and not the > opaque but that doesn't seem very helpful to me. It just adds a few extra lines > to the client code without a lot of gain. I keep switching back and forth between mails to find out what these parameters are supposed to mean (especially the NULL ones), so yes, I think even passing just the name and function pointers this way would improve readability. Kevin