Hi Eduardo,

I was not able to list cpu class properties with this command, but it might
be that I am missing something. Daniel proposed the following patch for cpu
class properties some time ago:
http://lists.gnu.org/archive/html/qemu-devel/2015-08/msg03117.html And my
patch just implements a command that will return properties for any class,
but not only for devices. There is another related thread
http://lists.nongnu.org/archive/html/qemu-devel/2016-01/msg04348.html

If there are any additional requirements or concerns, please let me know,
and I will change the patch.

Regards,
Valentin


On Sat, Jan 23, 2016 at 5:01 PM, Eduardo Habkost <[email protected]>
wrote:

> On Tue, Jan 12, 2016 at 02:50:20PM +0000, Daniel P. Berrange wrote:
> > On Tue, Jan 12, 2016 at 05:36:27PM +0300, Valentin Rakush wrote:
> > > This is RFC because implementation depends on the upcoming class
> > > properties
> > > http://lists.nongnu.org/archive/html/qemu-devel/2015-08/msg03115.html
> > > and also because this patch does not handle all x86_64 properties.
> > >
> > > This RFC is in response to concerns pointed in this review but with
> changed
> > > subject line as recommended.
> > > http://lists.nongnu.org/archive/html/qemu-devel/2016-01/msg00053.html
> > >
> > > This RFC demonstrates the way for displaying cpu properties using -cpu
> > > help option.
> >
> > The point of doing this with QOM class properties, is such that we can
> > create a facility to query class properties for any QOM type in a
> > consistent manner.  I was expecting this would take the form of a
> > QMP monitor command 'qom-type-properties' or something along those
> > lines.
>
> Also, note that qmp_device_list_properties() already does what
> you want to do, without requiring class-properties.
>
> This means you can implement the new interfaces (help output, QMP
> changes) without any new QOM core code. You can also propose QOM
> class-properties, if it helps making code simpler, but it's not a
> requirement for returning QOM properties on QMP/help output.
>
> --
> Eduardo
>



-- 
Best Regards,
Valentin Rakush.

Reply via email to