From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49827) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WwvAi-0002pS-R3 for qemu-devel@nongnu.org; Tue, 17 Jun 2014 11:19:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WwvAb-00055Z-Av for qemu-devel@nongnu.org; Tue, 17 Jun 2014 11:19:40 -0400 Received: from cantor2.suse.de ([195.135.220.15]:34898 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WwvAb-00055R-5C for qemu-devel@nongnu.org; Tue, 17 Jun 2014 11:19:33 -0400 Message-ID: <53A05C84.6050300@suse.de> Date: Tue, 17 Jun 2014 17:19:32 +0200 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1402505369-12526-1-git-send-email-pbonzini@redhat.com> <1402505369-12526-2-git-send-email-pbonzini@redhat.com> <53A04E1C.5080105@suse.de> <53A059CD.7050807@redhat.com> In-Reply-To: <53A059CD.7050807@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 1/5] qom: add a generic mechanism to resolve paths List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , qemu-devel@nongnu.org Cc: mtosatti@redhat.com, stefanha@redhat.com Am 17.06.2014 17:07, schrieb Paolo Bonzini: > Il 17/06/2014 16:18, Andreas F=E4rber ha scritto: >>> +void object_property_add_full(Object *obj, const char *name, const >>> char *type, >>> + ObjectPropertyAccessor *get, >>> + ObjectPropertyAccessor *set, >>> + ObjectPropertyResolve *resolve, >>> + ObjectPropertyRelease *release, >>> + void *opaque, Error **errp); >> >> I'm a bit concerned about the duplication going on here, e.g. of the >> forbidden characters. I think we should either just add the new argume= nt >> to object_property_add() and add NULL arguments at old call sites as >> done before, or we should (to avoid future _really_full, >> _really_really_full versions) return the resulting ObjectProperty * fo= r >> modification by the caller (in this case: ->resolve =3D foo). >=20 > The reason I went with "_full" is that the new argument is really neede= d > only in a minority of cases. There are ~50 occurrences right now, and = I > expect only a handful of them to need a ->resolve callback (and so far > all of them would be in qom/object.c). >=20 > There are many examples in glib's GSource (g_timeout_add_full, > g_main_context_invoke_full, etc.) or elsewhere in glib > (g_format_size_full). >=20 > Since we do not have an ABI to follow, we could add arguments to the > _full routine while keeping the shorthand version as is. >=20 > I can change the 50 occurrences if you want though. So what about my alternative suggestion of changing _add's void -> ObjectProperty*? That would limit future updating to the struct itself while still avoiding to touch the 50. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg