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

[Daniel P . Berrangé]

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.


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.

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.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|