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

[Paolo Bonzini]

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?

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

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?  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"?

Paolo