Re: [PATCH 0/6] qemu-storage-daemon: QAPIfy --chardev

[Markus Armbruster <armbru@redhat.com>]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Fri, Oct 23, 2020 at 12:12:16PM +0200, Kevin Wolf wrote:
>> While the qemu-storage-daemon command line is still considered unstable,
>> let's change --chardev from the old QemuOpts-based parser to QAPI, so
>> that it becomes a simple mapping of chardev-add to the command line and
>> will fit in a future fully QAPIfied command line without later
>> incompatible changes or additional compatibility glue.
>
> NB, I am *not* objecting to this series in what I'm about to write,
> but I want to point out that I don't think we should assume that
> this proposed QAPIified CLI is neccessarily the long term end point.
> Below I outline potential incompatible changes that would end up
> turning -chardev into legacy / deprecated syntax.
>
>
> The chardev QAPI-ification is a good example of the gap between QOM
> and QAPI.
>
> The chardev backends are QOM classes, but they lack the "user creatable"
> interface.
>
> Thus instead of configuring them using -object / object_add, we have a
> QAPI model, custom args/commands -chardev / chardev_add, and then code
> that populates the object instance properties from the QAPI model. Except
> we've not really exposed them as object instance properties - they are
> mostly just struct fields directly accessed.
>
>
> The benefit of the chardev approach is that we have an introspectable
> QAPI model. The downside is that we have a bunch of conversion code
> for QAPI to QOM mapping.
>
> The benefit of the user creatable object approach is that we dont
> have to add custom CLI args for different types of object, nor write
> code to populate QOM from QAPI. The downside is that we're divorced
> from the QAPI schema, so loose introspection, and have a different
> type of tedious boilerplate code to write.

Loss of QAPI introspection is the killer.

We have QOM introspection, but it's far too weak to serve as
replacement.  Besides, two introspection facilities is one too many.

> The fact that we have this custom -chardev arg, instead of just using
> -object is related to the ordering problems we have in main() in the
> system emulators.
>
> We have some -object types that need creating before the chardev
> types, and some -object types that need creating after the chardevs.
>
> If -chardev didn't exist, and we used -object for chardev creation,
> then the ordering problem would trivially not exist, as we would
> simply be processing all -object args in order that we receive them.
>
>
> IOW, if we're considering our ideal long term configuration goals
> for QEMU, then I think we should be looking at a solution to bridge
> the gap, so that we can get the best of both worlds, and have a single
> way todo things.
>
> IMHO, ideally none of -netdev, -chardev, -device, etc would exist
> in any "modern" CLI, they would just be considered legacy syntax.
> Essentially everything would be created using the same -object arg
> and object_add  commands.
>
>
> What I think this means is that we need to use QAPI to represent
> the properties of an object, and auto-generate the QOM code to
> register properties, provider setters/getters, constructors, etc.

Use of a QAPI schema rather than code to define user-facing QOM
properties provides QAPI introspection for QOM.  Having that would be
lovely.

Bonus: in QOM, documenting types takes effort.  Consequently,
user-facing QOM is mostly undocumented.  In a QAPI schema, *not*
documenting stuff takes effort: the QAPI generator insists on
documentation.

Eduardo (cc'ed) mentioned he'd like to work towards defining properties
in a QAPI schema.

> For existing user creatable objects this would largely involve
> deleting lots of existing code and defining some simple QAPI
> schemas. This is probably quite easy, if tedious.
>
> For the chardev/netdev/etc objects we already have the QAPI schema,
> but would need to add code genration parts to turn them into full
> user creatable object classes. This is likely harder more involved
> work, especially to keep backcompat working well.

I sympathize with this long term vision.

Nevertheless, we need Kevin's work now to get a decent storage daemon
CLI while that's still easy to do.  We'll have to promise stability
soon, and then changes get much harder.