On Wed, 08 Jan 2014 18:33:11 +0100 Paolo Bonzini <pbonz...@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
