On 30/07/20 12:03, Markus Armbruster wrote:
> qdev C layer:
>
> frob->prop = 42;
>
> Least cognitive load.
>
> QOM has no C layer.
Not really, a QOM object is totally free to do frob->prop = 42. And
just like we didn't do that outside device implementation in qdev as our
tithe to the Church of Information Hiding; the same applies to QOM.
> qdev property layer works even when @frob has incomplete type:
>
> qdev_prop_set_int32(DEVICE(frob), "prop", 42);
>
> This used to map property name to struct offset & copy the value.
> Simple, stupid.
>
> Nowadays, it is the same as
>
> object_property_set_int(OBJECT(frob), "frob", 42, &error_abort);
>
> which first converts the int to a QObject, then uses a QObject input
> visitor with a virtual walk to convert it back to int and store it in
> @frob. It's quite a sight in the debugger.
Yes, but thatt's just because we never bothered to create single-type
visitors. For a good reason though: I don't think the extra QAPI code
is worth (not even that much) nicer backtraces when we already have a
QObject as a battle-tested variant type.
> qdev "text" layer is really a QemuOpts layer (because that's what we had
> back then). If we have prop=42 in a QemuOpts, it calls
>
> set_property("prop", "42", frob, &err);
>
> Nowadays, this is a thin wrapper around object_property_parse(),
> basically
>
> object_property_parse(frob, "prop", 42, &err);
>
> Fine print: except set_property() does nothing for @prop "driver" and
> "bus", which look just like properties in -device / device-add, but
> aren't.
Ugly indeed. They should be special cased up in the caller, probably,
or use the long-discussed "remainder" feature of the QAPI schema.
> object_property_parse() uses the string input visitor, which I loathe.
Apart from the list syntax, the string input visitor is decent I think.
>>> I've long had the nagging feeling that if we had special-cased
>>> containers, children and links, we could have made a QOM that was easier
>>> to reason about, and much easier to integrate with a QAPI schema.
>>
>> That's at least plausible. But I have a nagging feeling that it would
>> only cover 99% of what we're doing with QOM. :)
>
> The question is whether that 1% really should be done the way it is done
> :)
And that's a very fair question, but it implies non-trivial design work,
so the smiley changes to a frown. :(
Paolo
