Daniel P. Berrangé <berra...@redhat.com> writes: > On Tue, May 13, 2025 at 11:26:31AM +0200, BALATON Zoltan wrote: >> On Tue, 13 May 2025, Markus Armbruster wrote: >> > Mark Cave-Ayland <mark.caveayl...@nutanix.com> writes: >> > > On a related note this also brings us back to the discussion as to >> > > the relationship between qdev and QOM: at one point I was under the >> > > impression that qdev properties were simply QOM properties that were >> > > exposed externally, i.e on the commmand line for use with -device. >> > > >> > > Can you provide an update on what the current thinking is in this >> > > area, in particular re: scoping of qdev vs QOM properties? >> > >> > qdev is a leaky layer above QOM. >> > >> > qdev properties are also QOM properties. >> > >> > All device properties are exposed externally. >> >> That was clear but the question was if QOM properties (that are not qdev >> properties) exist and if so are they also exposed? If not exposed it may be >> used for internal properties (where simpler solutions aren't convenient) but >> maybe qdev also adds easier definition of properties that's why they used >> instead of QOM properties? > > NB, not everything we expose is a QDev. We directly expose QOM > via "-object" if they implement the 'UserCreatable' interface. > If we want internal properties, that should likely be wired in > to the QOM level directly.
Yes. As is, all properties of QOM types implementing UserCreatable are part of the -object / object_add stable external interface. We lack means to add properties just for internal use. Properties of all QOM types (UserCreatable or not) are exposed externally via qom-get & friends. This isn't a stable interface except when it is, but that's a separate problem. > Conceptually you could even say that everything QEMU creates should > live under -object, and no other args ought to need to exist. We have > decades of evolved code making that impractical though. I doubt we would've invented qdev had QOM existed already.
