[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 0/5] -object/object-add support custom location an
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [RFC 0/5] -object/object-add support custom location and 2nd stage initialization |
Date: |
Fri, 10 Jan 2014 12:38:57 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9 |
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
patch. Instead, UserCreatable's complete method would redirect to the
backend-specific API.
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.
> 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. :)
Paolo
- [Qemu-devel] [PATCH 4/5] vl.c: -object: handle duplicate 'id' properly, (continued)