[PATCH v4 2/4] hw/i386: Attach CPUs to machine

[Peter Maydell]

On Mon, 7 Feb 2022 at 11:56, Daniel P. Berrangé <berrange at redhat.com> wrote:
> AFAIK, we've never defined anything about QOM paths wrt ABI one way
> or the other ? In the absence of guidelines then it comes down to
> what are reasonable expectations of the mgmt app. These expectations
> will be influenced by what it is actually possible to acheive given
> our API as exposed.
>
> I think it is unreasonable to expect /machine/unattached to be
> stable because by its very nature it is just a dumping ground
> for anything where the dev hasn't put in any thought to the path
> placement.  IOW, it was/is definitely a bad idea for libvirt to
> rely on /machine/unattached in any way. That we're liable to be
> broken is not nice, but its really our own fault - we should
> have asked for a better solution from day one here.
>
>
> I think it is somewhat reasonable to expect other QOM paths to
> be stable as there's been some degree of thought put into their
> placement. If we don't want apps to be considering other
> paths to be stable, then we need to explain exactly what they
> can and can't rely on, and most importantly actually provide
> a way for them to do what they need

I wouldn't personally expect other QOM paths to be stable
except in the sense of "probably don't change very often".
There are internal-to-QEMU code refactorings and rearrangements
that will change QOM paths, and there is no clear "warning,
don't change this stuff" to point people away from making
that kind of code change, nor are there tests in the test suite
that will catch accidental changes.

-- PMM