Re: [Qemu-devel] [RFC 0/5] -object/object-add support custom location and 2nd stage initialization

[Igor Mammedov <imammedo@redhat.com>]

On Wed, 08 Jan 2014 18:33:11 +0100
Paolo Bonzini <pbonzini@redhat.com> wrote:

> Il 08/01/2014 17:51, Igor Mammedov ha scritto:
> >> > 
> >> > Thanks Igor!  I like very much patches 1-4 (though I'm thinking that we
> >> > need some style conventions for interfaces).  I think patch 5 adds more
> >> > complexity than we need, but I'm open to discussion.
> > I'm sorry that it took so long.
> > The reason for separate interfaces is that realize interface is more generic
> > and might be used outside of '-object'. While I don't see 'path' interface
> > ever used outside of -object.
> 
> Yeah, I think the two interfaces are a good idea.  The question is
> whether we want the second interface at all.  I think it's fine to
> delegate namespace conventions to management.
with dropping it, backends for sure can work without it, they will be just
placed directly under "/objects". For memdev backend it might be upto 256
objects, clattering "/objects" container.
Stefan had the similar idea about grouping iothread objects inside
"/backends/iothreads".


> 
> 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.

how about naming it for what it is: object-2nd-stage-init or neutral
object-complementary-interface that could be extended later with
another methods (we could event squash path interface in it in the last case)

> Paolo


-- 
Regards,
  Igor