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

[Markus Armbruster <armbru@redhat.com>]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 23/10/20 15:40, Markus Armbruster wrote:
>>>
>>> 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.
>
> Wouldn't Eduardo+Kevin's work on object-add provide that too?

Yes, the issue "replacing chardev-add by object-add loses QAPI
introspection" evaporates when object-add becomes QAPI-introspectable.

>> 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.
>
> I think we haven't answered the question of whether qsd needs a CLI at all.
>
> I looked recently at qemu_init and it struck me that, in principle, the
> only _really_ necessary command line options for QEMU are -sandbox,
> -name and possibly -trace (only to be able to trace the monitor).  For
> everything else, one could use LISTEN_FDS socket activation mechanism,
> or if there's no LISTEN_FDS environment variable open a QMP socket on
> stdin/stdout.

Nobody argues this can't be done.  Some of us argue it should not be
done :)

> For qemu-standard-daemon, that would be _really_ true and not just in
> principle I understand that having a command-line can be useful to
> developers as it's less unwieldy than JSON, but why does it have to be
> stable?

Let me split this into multiple questions:

1. Does qsd need a CLI beyond whatever is needed to provide QMP?

2. If yes, does it need to be stable?

3. Does it need to be machine-friendly?

4. Does it need to be human-friendly?

5. What does it mean to be human-friendly?

I'd expect Kevin to answer question 1. and 4. with an emphatic yes.  I
concur, because without a usable CLI, ad hoc usability is awful.  My
idea of "usable" is probably less demanding than Kevin's, but that's
question 5 already.

The step from a QMP command that returns nothing to machine-friendly CLI
option is almost trivial: -blockdev with a JSON argument proves it.
This makes me answer 3. with "why not?", and 2. with "this
machine-friendly interface is stable by construction".

We already paid for the step from machine-friendly CLI to a slightly
more human-friendly CLI: -blockdev with a dotted keys argument proves
it.  This makes me answer 4. with "why not / why override the qsd
maintainer?"

Question 5. is open-ended.  I think a truly human-friendly CLI will take
extra work, similar to how HMP does.  I believe it can be done with less
overhead than HMP has today.  I don't plan to sink a lot of time into it
myself, at least not in the immediate future.

>          Could we default to only 2-3 command-line options in the same
> fashion, and only accept --blockdev and friends if the user starts the
> command line with "qemu-storage-daemon --i-am-not-a-script"?

Making people type --i-am-not-a-script is begging for getting pelted
with vegetables at the next non-virtual KVM Forum.

I think what you're trying to accomplish is to tell a program off when
it uses a part of the CLI programs should not use.  My "Configurable
policy for handling deprecated interfaces" series can grow to do exactly
that, but it's opt-in (because I don't fancy getting pelted with
vegetables).