On Fri, Sep 22, 2017 at 12:18:44PM +0200, Paolo Bonzini wrote:
> On 22/09/2017 12:16, Stefan Hajnoczi wrote:
> > I suggest adding internal IOThreads alongside user-created IOThreads
> > instead of hiding them. IOThread also needs a bool user_created field
> > and a UserCreatableClass->can_be_deleted() function:
> >
> > static bool iothread_can_be_deleted(UserCreatable *uc)
> > {
> > return IOTHREAD(uc)->user_created;
> > }
> >
> > This way users cannot delete internal IOThreads.
> >
> > But how should object ids be handled? In theory existing -object
> > iothread,id=<id> users could use any name. How can QEMU generate ids
> > for internal IOThreads without conflicting with existing users's ids?
>
> I would add an 'internal' boolean to query-iothreads' response and a new
> 'show-internal' boolean to the command. This way, applications that
> request internal iothreads would know that the "primary key" is
> (internal, id) rather than just the id.
What is the app going to do with iothreads if it sees "internal" flag
set ? They have no way of knowing what part of QEMU internally is using
this iothread, so I don't see that they can do anything intelligent
once they find out they exist.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
