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

[Kevin Wolf]

Am 23.10.2020 um 12:36 hat Daniel P. Berrangé geschrieben:
> 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.

Well, when do we have an end point for anything anyway? Things will
always evolve.

> 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.

They aren't really proper QOM classes at this point. Technically they
are, but they are pretty boring QOM classes that don't have any
properties. Instead, they use ChardevBackend QAPI objects in the custom
ChardevClass.open method.

So they are in some weird in-between state.

> 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.

I think we need to distinguish legacy options and convenience options
(and this applies much more broadly than just here, and it's probably
more important in other places).

Even if we eventually make -object capable of configuring chardev and
netdev backends, -chardev could still be more convenient to use for a
human user.

This equation of "legacy" and "convenience" is also on of the problems I
have with the suggestion of having two binaries for "legacy" and
"modern" interfaces. Humans are not legacy, and having a command line
that is unfriendly for human users doesn't make it modern.

We have a lot of legacy stuff in the command line, and the goal for it
is to get rid of it and replace it with something modern (the goal is
_not_ keeping it around for human users because compatibility with this
legacy stuff often blocks us from moving forward).

But convenience options for human users aren't bad at all, as long as
they are based on a modern model of how things work. We'll always want
to have some.

Sorry for going on a tangent... Back to chardev: In the end, the
preferred command line interface doesn't matter that much. The required
structure will be the same.

> 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.

Yes, I agree with this one.

I expect we'll discuss this more when I send the first step for
object-add (which is QMP, so for everything, not just
qemu-storage-daemon), which will duplicate the QOM properties in the
QAPI schema for user creatable objects. Generating QOM code from the
schema should be the next step then.

> 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.

The challenging part is probably not keeping compatibility (there's no
reason to break it if it represents everything well), but that these are
union types in the QAPI schema that map to different QOM classes.

It's not entirely obvious to me yet how we would deal with this, but the
good thing is that this is all about internal interfaces which we can
change relatively freely.

Kevin