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