From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48575) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1dKT-0002VV-SR for qemu-devel@nongnu.org; Fri, 10 Jan 2014 09:45:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1dKK-00041c-FE for qemu-devel@nongnu.org; Fri, 10 Jan 2014 09:44:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:58949) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1dKK-00041F-6m for qemu-devel@nongnu.org; Fri, 10 Jan 2014 09:44:48 -0500 Date: Fri, 10 Jan 2014 15:44:38 +0100 From: Igor Mammedov Message-ID: <20140110154438.4d4fd23b@nial.usersys.redhat.com> In-Reply-To: <52CFDBD1.5030705@redhat.com> References: <1389197382-25085-1-git-send-email-imammedo@redhat.com> <52CD7BBF.3030202@redhat.com> <20140108175159.029e5f9e@nial.usersys.redhat.com> <52CD8BD7.8070706@redhat.com> <20140110122810.7d34b120@thinkpad> <52CFDBD1.5030705@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC 0/5] -object/object-add support custom location and 2nd stage initialization List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: aliguori@amazon.com, sw@weilnetz.de, mjt@tls.msk.ru, qemu-devel@nongnu.org, lcapitulino@redhat.com, blauwirbel@gmail.com, stefanha@redhat.com, afaerber@suse.de, rth@twiddle.net On Fri, 10 Jan 2014 12:38:57 +0100 Paolo Bonzini wrote: > Il 10/01/2014 12:28, Igor Mammedov ha scritto: > >> > Regarding the "overloading" of the realize name, I was against it in > >> > previous discussion and I still am (I was in favor of something like > >> > UserCreatable and naming the method "complete" or "construct"), but I > >> > didn't want to sound too negative. :) > > issue with naming interface as CommandLine or UserCreatable is that, it could > > be used not only by CLI/user but also it could be used internally. For example > > see "[PATCH 3/5] virtio_rng: use object_realize interface instead of calling > > backend API", where default backend is created by frontend. > > I see. Yes, with something like UserCreatable, you would not have that I'm not sure why I wouldn't have that path. It does exactly what you've just written vvv, > patch. Instead, UserCreatable's complete method would redirect to the > backend-specific API. i.e. it calls cast(default_rng).complete() which redirects to backend specific API, where UserCreatable.complete() is rng_backend_realize() > > BTW, note that UserCreatable's complete method should take a > UserCreatable (or whatever the name is) as the first parameter, not an > Object. This would affect that patch, too. It does, 'void (*realize)(ObjectRealizeInterface *obj, Error **errp);' call_object_realize_interface(Object *obj,...) is a wrapper that reduces casting code duplication at call sites since it's used at more then 1 place. > > > how about naming it for what it is: object-2nd-stage-init > > That would also work for me (TwoStageConstructable or something like that). > > One advantage of UserCreatable is that -object/object_add could check > for it and reject creation of objects that are not meant for > command-line instantiation. You could do the same for > TwoStageConstructable, but it would look weird to define an object as > two-stage constructable with an empty complete method. > > With a name like UserCreatable, instead, it would be quite natural to do > this: > > void user_creatable_complete(UserCreatable *uc, Error **errp) > { > UserCreatableClass *ucc = USER_CREATABLE_GET_CLASS(uc); > if (ucc->complete) { > ucc->complete(uc, errp); > } > } > > > neutral object-complementary-interface that could be extended later with > > another methods > > No, we don't want a hodge-podge interface that's basically UserCreatable > except in the name. :) I'm fine with UserCreatable, lets wait couple days if there is no objection or another suggestions and I'll then respin series. > > Paolo