[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 00/18] qapi/qom: QAPIfy object-add

From: Paolo Bonzini
Subject: Re: [PATCH 00/18] qapi/qom: QAPIfy object-add
Date: Wed, 2 Dec 2020 10:30:11 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

On 01/12/20 23:08, Eduardo Habkost wrote:
Properties are only a useful concept if they have a use.  If
-object/object_add/object-add can do the same job without properties,
properties are not needed anymore.

Do you mean "not needed for -object anymore"?  Properties are
still used by internal C code (esp. board code),
-device/device_add, -machine, -cpu, and debugging commands (like
"info qtree" and qom-list/qom-get/qom-set).


Right now QOM is all about exposing properties, and having multiple
interfaces to set them (by picking a different visitor).  But in practice
most QOM objects have a lifetime that consists of 1) set properties 2) flip
a switch (realized/complete/open) 3) let the object live on its own.  1+2
are a single monitor command or CLI option; during 3 you access the object
through monitor commands, not properties.

I agree with this, except for the word "all" in "QOM is all
about".  QOM is also an extensively used internal QEMU API,
including internal usage of the QOM property system.

Yeah, "all about exposing properties" includes internal usage. And you're right that some "phase 3" monitor commands do work at the property level (mostly "info qtree", but also "qom-get" because there are some cases of public run-time properties).

I'm liking the direction this is taking.  However, I would still
like to have a clearer and feasible plan that would work for
-device, -machine, and -cpu.

-cpu is not a problem since it's generally created with a static configuration (now done with global properties, in the future it could be a struct).

-machine and -device in principle could be done the same way as -object, just through a different registry (_not_ a huge struct; that's an acceptable stopgap for -object but that's it). The static aka field properties would remain as read-only, with defaults moved to instance_init or realize. But there would be again "triplication" with a trivial conversion:

1) in the QAPI schema, e.g. 'num_queues': 'int16'

2) in the struct, "int16_t num_queues;"

3) in the realize function,

    s->num_queues = cfg->has_num_queues ? cfg->num_queues : 8;

So having a mechanism for defaults in the QAPI schema would be good. Maybe 'num_queues': { 'type': 'int16', 'default': '8' }?

I also need to review more the part of this code with respect to the application of global properties. I wonder if there are visitor tricks that we can do, so that global properties keep working but correspond to QAPI fields instead of QOM properties.


reply via email to

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