Re: [PATCH v2 00/21] qom: introduce property flags to track external user input

[Markus Armbruster <armbru@redhat.com>]

I can't find a good spot in the existing discussion where the following
would fit neatly as a reply, so I'm starting at the top again.

Fact: a huge part of our external interface is *accidental* and
virtually undocumented.

The sane way to do an external interface is to layer it on top of more
powerful internal interfaces.  The external interface exposes just the
functionality that's wanted there.  The internal interfaces can evolve
without affecting the external one.

QMP works that way.  QEMU code uses internal C interfaces.  QEMU doesn't
send QMP commands to itself.  If we need something internally, we add it
to a suitable internal interface.  There's no need to add it to the
external interface just for that.

QOM does not work that way.  The internal and the external object
configuration interface is one and the same.  So, if we add a property
for internal use, we can't *not* add it to the external interface.

This has led to an external interface that is frickin' huge: I count
~1000 device types with ~16000 properties in qemu-system-aarch64 alone.
The vast majority is undocumented.

Time and again we've found ourselves unsure whether certain properties
have external uses, or are even meant for external use.

We have been unable / unwilling to isolate the external interface from
internal detail.  This is madness.

As long as we persist in this madness, a sane, properly documented
external interface will remain impossible.

Do we care?  If yes, we should discuss how to isolate external and
internal interfaces.

This series attempts to create a bit of infrastructure for such
isolation: means to mark properties as internal.  Is it the right
infrastructure?  Is it enough to be a useful step?  Maybe not, but then
I'd like to hear better ideas.




Prior discussion in this thread:

    Subject: How to mark internal properties (was: Re: [PATCH v4 12/27]
        target/i386/cpu:  Remove CPUX86State::enable_cpuid_0xb field)
    Date: Fri, 9 May 2025 12:04:19 +0200
    Message-ID: <2f526570-7ab0-479c-967c-b3f95f9f19e3@redhat.com>
    https://lore.kernel.org/qemu-devel/2f526570-7ab0-479c-967c-b3f95f9f19e3@redhat.com