On Wed, Jan 19, 2022 at 5:12 AM Markus Armbruster <arm...@redhat.com> wrote: > > Damien Hedde <damien.he...@greensocs.com> writes: > > > Hi Mirela, > > > > On 1/11/22 17:54, Mirela Grujic wrote: > >> Hi, > >> > >> While working on a prototype and configuring a whole machine using > >> QMP we run into the following scenario. > >> > >> Some device models use array properties. > > A gift that keeps on giving... > > >> The array is allocated when > >> len-<arrayname> property is set, then, individual elements of the > >> array can be set as any other property (see description above the > >> DEFINE_PROP_ARRAY definition in qdev-properties.h for more > >> details). We need to do both (allocate the array and set its > >> elements) before the device can be realized. Attempting to set > >> len-<arrayname> and array elements in a single device_add command > >> does not work because the order of setting properties is not > >> guaranteed, i.e. we're likely attempting to set an element of the > >> array that's not yet allocated. > > > > It happens because device options are stored in an optdict. When this > > optdict is traversed to set the qdev-properties, no specific order is > > used. > > To be precise: it's stored in a QDict[*] > > qdev_device_add_from_qdict() sets properties with > object_set_properties_from_qdict(), which iterates over the QDict in > unspecified order. > > > Better json format support would probably solve this issue in the > > long-term. But right now, we are stuck with the optdict in the middle > > which do not support advanced structure like lists or dictionaries. > > I figure you mean actual array-valued properties, like > > 'foo': [ 1, 2, 3 ] > > instead of > > 'len-foo': 3, 'len[0]': 1, 'len[1]': 2, 'len[2]': 3 > > > We could solve this by being more "smart" in when setting the > > properties. I'm not sure we can be really smart here and detect which > > options is an array length but we could at least have some heuristic > > and for example: set first "len-xxx" properties so that array will be > > allocated before being filled. > > Ugh! > > Another stop gap solution could be making QDict iterate in insertion > order, like Python dict does since 3.6. >
I like this idea, I think. Are there any possible downsides here? Making the order more 'stable' in one regard might lead to people trusting it "too often" if there are other implementation details that might impact the order ... but I don't actually have any examples handy for that. It's just my fear. --js
