On Fri, Nov 04, 2016 at 04:45:17PM +0100, Markus Armbruster wrote: > Eduardo Habkost <ehabk...@redhat.com> writes: > > > (CCing libvirt people, as I forgot to CC them) > > > > On Mon, Oct 31, 2016 at 03:07:23PM +0100, Igor Mammedov wrote: > >> On Fri, 28 Oct 2016 23:48:06 -0200 > >> Eduardo Habkost <ehabk...@redhat.com> wrote: > >> > >> > When an abstract class is used on device-list-properties, we can > >> > simply return the class properties registered for the class. > >> > > >> > This will be useful if management software needs to query for > >> > supported options that apply to all devices of a given type (e.g. > >> > options supported by all CPU models, options supported by all PCI > >> > devices). > >> Patch looks fine to me but I'm not qmp interface guru > >> so I'd leave review up to maintainers. > >> > >> One question though, > >> How would management software discover typename of abstract class? > > > > It depends on the use case. On some cases, management may already > > have bus-specific logic that will know what's the base type it > > needs to query (e.g. it may query "pci-device" to find out if all > > PCI devices support a given option). On other cases, it may be > > discovered using other commands. > > The stated purpose of this feature is to let management software "query > for supported options that apply to all devices of a given type". I > suspect that when management software has a notion of "a given type", it > knows its name. > > Will management software go fishing for subtype relationships beyond the > types it knows? I doubt it. Of course, management software developers > are welcome to educate me :) > > > For the CPU case, I will propose adding the base QOM CPU typename > > in the query-target command. > > Does this type name vary? If yes, can you give examples?
It does. x86-specific CPU properties are on the x86_64-cpu and i386-cpu classes. arm-specific CPU properties are on the arm-cpu class. > > >> Perhaps this patch should be part of some other series. > > > > This is a valid point. In this case, it depends on the approach > > we want to take: do we want to provide a flexible interface for > > management, let them find ways to make it useful and give us > > feedback on what is lacking; or do we want to provide the new > > interface only after we have specified the complete solution for > > the problem? > > > > I don't know the answer. I will let the qdev/QOM/QMP maintainers > > answer that. > > I'm reluctant to add QMP features just because we think they might be > useful to someone. We should talk to users to confirm our hunch before > we act on it. > > That said, this one isn't exactly a biggie. Considering we are past soft freeze, I can document a more concrete usage example when I submit the next version. -- Eduardo
