Paolo Bonzini <pbonz...@redhat.com> writes: > Il mer 15 gen 2020, 10:21 Markus Armbruster <arm...@redhat.com> ha scritto: > >> > We don’t want the QAPI to let arbitrary fields of a QOM object >> > be modified, do we? >> >> We already do: QMP command qom-set. If it breaks your guest, you get to >> keep the pieces. >> > > That's not true. We chose not to make that a "recommended" interface, and > instead we add new commands. However that's mostly to avoid tying our hands > and not making too much of QOM part of the API. But I would be very > surprised if a guest could be broken with qom-set. > > This was definitely not the case when QOM was introduced in a half-baked > state, but let's not indulge in self-flagellation more than it's actually > necessary.
Nobody thinks of qom-set when adding a QOM property. qom-set runs a setter function that can do anything. Is that safe at any point of time? Depends. Fortunately, most setters merely write to some object instance variable. Often, the object's code reads the instance variable only in realize(), and never writes to it. qom-set is safe then, but not terribly useful. More interesting are the ones that are read and written throughout the object's life cycle. Is qom-set safe at any point of time? Depends. Your belief qom-set can't break a guest in practice is reassuring. However, the point I was trying to make with "you get to keep the pieces" is precisely that we're "not making too much of QOM part of the API". An additional point I'd like to repeat now: which parts of QOM are is pretty much anybody's guess.
