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
