[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 13:41:41 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

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

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).


reply via email to

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