From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60439) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1eCS-0004Vd-TF for qemu-devel@nongnu.org; Fri, 10 Jan 2014 10:40:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1eCK-0004f7-FD for qemu-devel@nongnu.org; Fri, 10 Jan 2014 10:40:44 -0500 Received: from mail-ee0-x22a.google.com ([2a00:1450:4013:c00::22a]:61543) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1eCK-0004f0-2m for qemu-devel@nongnu.org; Fri, 10 Jan 2014 10:40:36 -0500 Received: by mail-ee0-f42.google.com with SMTP id e49so266563eek.29 for ; Fri, 10 Jan 2014 07:40:33 -0800 (PST) Sender: Paolo Bonzini Message-ID: <52D0146C.70505@redhat.com> Date: Fri, 10 Jan 2014 16:40:28 +0100 From: Paolo Bonzini MIME-Version: 1.0 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> <20140110154438.4d4fd23b@nial.usersys.redhat.com> In-Reply-To: <20140110154438.4d4fd23b@nial.usersys.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 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: Igor Mammedov Cc: stefanha@redhat.com, sw@weilnetz.de, mjt@tls.msk.ru, qemu-devel@nongnu.org, lcapitulino@redhat.com, blauwirbel@gmail.com, aliguori@amazon.com, afaerber@suse.de, rth@twiddle.net Il 10/01/2014 15:44, Igor Mammedov ha scritto: > 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, You're right, I misremembered. >> 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. This is needed only because you allow creating objects that do not have ObjectRealizeInterface. With a UserCreatable interface, the dynamic cast would be in vl.c and qmp.c (to check whether the user is actually allowed to use -object on that device) and there's no duplication at the call sites of the 2nd-stage init method. > I'm fine with UserCreatable, lets wait couple days if there is no objection > or another suggestions and I'll then respin series. Thanks! Paolo