On Tue, Jan 07, 2020 at 06:11:13PM +0100, Christophe de Dinechin wrote:
> > On 20 Dec 2019, at 17:13, Stefan Hajnoczi <stefanha@gmail.com> wrote:
> So I think that Daniel is right. We may need at some point to start
> a NEMU-style offshoot that does not attempt to be compatible,
> but explores describing an increasing surface of the API using a
> new meta-language from which we can generate, in a consistent
> way, at least:
> 
> - C bindings
> - Command-line options
> - Shell bindings (or “HMP”)
> - JSON schema or qom description
> - Bindings in other languages (Rust, Go, Python)
> - Networked versions of the API (socket, REST)
> - Client-side code e.g. for libvirt.
> - Serialization / deserialization, e.g. for configuration files
> - Documentation, including man page and API docs
> - Command-line help
> 
> At the most fundamental level, I think we need to describe:
> 
> - Values, e.g. how we represent names, sizes, paths, etc, possibly
> with some user-friendly aspects, e.g. path shortcuts, memory units,
> spelling shortcuts (e.g. being able to consistently say -blo for -blockdev
> if that’s the shortest option that matches)
> - Relations, e.g. how we represent “contains”, “derives from”, “needs”,
> “one of”, “one or several”, “attaches to”…
> - States, e.g. how do we represent the machine configuration,
> or the desired new disk setting
> - Verbs, e.g. how we represent “add”, “connect”, “remove”, “find”,
> “start”, “notify”, etc. and how we describe the kind of input they need.
> - Possibly more subtle things like support for transactions, commit/rollback,
> i.e. “I want to add connect a virtual nic to some host vf, but if anything
> along the way fails, I’d like all the cleanup to happen automatically)

Extending QAPI to achieve these things is a possibility.

If we afford ourselves the luxury of breaking backwards compatibility
then I would instead use the opportunity to eliminate complexity:
1. Get rid of the CLI
2. Get rid of HMP
3. No per-command C bindings, just a qmp_call() API
4. No configuration file, just a sequence of QMP commands

The new QEMU would be very different and solely focussed on QMP (or a
standards-based RPC system).

It's not very fun working on projects that have a lot of custom
infrastructure.  Making a one-time change requires a lot of learning
weird infrastructure that you won't use often.  We already have too much
of this and it slows down QEMU development.

Stefan