Paolo Bonzini <pbonz...@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).
