Re: [PATCH 00/18] qapi/qom: QAPIfy object-add
On 02/12/20 11:27, Kevin Wolf wrote:
> Declaring read-only QOM properties is trivial.
Trivial sounds like it's something the computer should be doing.
Possibly, but not necessarily. There's always a cost to automatic code
generation. If things are _too_ trivial and easy to get right, the cost
of automatic code generation exceeds the cost of doing things by hand.
You pretty much proved that ucc->complete is hard enough to get right,
that it benefits from code generation. But I am a bit more conservative
about extending that to the rest of QOM.
> I'm just worried about having yet another incomplete
transition.
Would you really feel at home in a QEMU without incomplete transitions?
One can always dream. :)
But since you had already posted RFC patches a while ago to
address this, I considered it solved.
Yup, I posted the non-RFC today.
1. This series (mostly for documentation and introspection)
2. -object and HMP object_add (so that we get QAPI's validation, and to
make sure that forgetting to update the schema means that the new
options just doesn't work)
3. Create a separate 'object' entity in QAPI, generate ucc->complete
implementations that call a create function in the C source code with
type-specific parameters (like QMP command handlers)
If we agree on all of these that's already a pretty good place to be in.
The decreasing length of the replies to the thread suggests that we are.
I wouldn't mind an example of (3) that is hand-coded and may only work
for one object type (even a simple one such as iothread), to show what
the generated QAPI code would look like. It's not a blocker as far as I
am concerned, but it would be nice.
More important, Markus and John should agree with the plan before (1) is
committed. That may also require the aforementioned example, but it's
up to them.
What's still open: Should QAPI cover run-time properties, too?
Should
run-time properties even exist at all in the final state? What is the
exact QAPI representation of everything? (The last one includes that I
need to have a closer look at how QAPI can best be taught about
inheritance.)
Run-time properties will exist but they will probably be cut down
substantially, and most of them will be read-only (they already are as
far as external code is concerned, i.e. they have a setter but qom-set
always fails because it's called too late).
Paolo