Daniel P. Berrangé <berra...@redhat.com> writes: > On Fri, Jul 08, 2022 at 01:40:43PM +0200, Markus Armbruster wrote: >> Cc'ing QOM maintainers. >> >> Peter Maydell <peter.mayd...@linaro.org> writes: >> >> > On Mon, 4 Jul 2022 at 05:50, Markus Armbruster <arm...@redhat.com> wrote: >> >> My initial (knee-jerk) reaction to breaking array properties: Faster, >> >> Pussycat! Kill! Kill! >> > >> > In an ideal world, what would you replace them with? >> >> Let's first recapitulate their intended purpose. >> >> commit 339659041f87a76f8b71ad3d12cadfc5f89b4bb3q >> Author: Peter Crosthwaite <peter.crosthwa...@xilinx.com> >> Date: Tue Aug 19 23:55:52 2014 -0700 >> >> qom: Add automatic arrayification to object_property_add() >> >> If "[*]" is given as the last part of a QOM property name, treat that >> as an array property. The added property is given the first available >> name, replacing the * with a decimal number counting from 0. >> >> First add with name "foo[*]" will be "foo[0]". Second "foo[1]" and so >> on. >> >> Callers may inspect the ObjectProperty * return value to see what >> number the added property was given. >> >> Signed-off-by: Peter Crosthwaite <peter.crosthwa...@xilinx.com> >> Signed-off-by: Andreas Färber <afaer...@suse.de> >> >> This describes how they work, but sadly not why we want them. For such >> arcane lore, we need to consult a guru. Possibly via the mailing list >> archive. > > Also doesn't describe why we need to explicitly set the array length > upfront, rather than inferring it from the set of elements that are > specified, auto-extending the array bounds as we set each property. > >> Digression: when you add a feature, please, please, *please* explain why >> you need it right in the commit message. Such rationale is useful >> information, tends to age well, and can be quite laborious to >> reconstruct later. >> >> Even though I'm sure we discussed the intended purpose(s) of array >> properties before, a quick grep of my list archive comes up mostly >> empty, so I'm falling back to (foggy) memory. Please correct mistakes >> and fill in omissions. >> >> We occasionally have a need for an array of properties where the length >> of the array is not fixed at compile time. Say in code common to >> several related devices, where some have two frobs, some four, and a >> future one may have some other number. >> >> We could define properties frob0, frob1, ... frobN for some fixed N. >> Users have to set them like frob0=...,frob1=... and so forth. We need >> code to reject frobI=... for I exeeding the actual limit. >> >> Array properties spare developers picking a fixed N, and users adding an >> index to the property name. Whether the latter is a good idea is >> unclear. We need code to reject usage exceeding the actual limit. > > If we consider that our canonical representation is aiming to be QAPI, > and QAPI has unbounded arrays, then by implication if we want a mapping > to a flat CLI syntax, then we need some mechanism for unbounded arrays. > > It would be valid to argue that we shouldn'be be trying to map the full > expressiveness of QAPI into a flat CLI syntax though, and should just > strive for full JSON everywhere. > > Indeed every time we have these discussions, I wish we were already at > the "full JSON everywhere" point, so we can stop consuming our time > debating how to flatten JSON structure into CLI options. But since > these array props already exist, we need to find a way out of the > problem...
This isn't just a CLI problem, it's worse: we have property-setting code that relies on "automatic arrayification".
