[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paolo Bonzini
Subject: Re: [PATCH 0/6] qemu-storage-daemon: QAPIfy --chardev
Date: Fri, 23 Oct 2020 18:08:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]