qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]