On Fri, Dec 20, 2019 at 04:13:59PM +0000, Stefan Hajnoczi wrote: > Hi, > QEMU presents a command-line interface and QMP monitor for > applications to interact with. Applications actually need API > bindings in their programming language. Bindings avoid reimplementing > code to spawn a QEMU process and interact with QMP. QEMU is kind of > lazy and de facto relies on libvirt for API bindings.
Just wanted to add that for a concrete example you might want to look at how libguestfs launches qemu, either directly: https://github.com/libguestfs/libguestfs/blob/master/lib/launch-direct.c or via libvirt: https://github.com/libguestfs/libguestfs/blob/master/lib/launch-libvirt.c Obviously I support anything that makes that easier, especially the direct case. Some points that you didn't cover: - Any APIs we use need to be callable from a C library. This has a few weird and wonderful beartraps to be aware of, such as being unable to predict the state of signal masks, not knowing what file descriptors will be open, and being religious about cleaning up any resources or subprocesses that you allocate / fork. - To be usable, the new APIs need to cover everything that libguestfs needs, otherwise we literally cannot switch over to them. (I guess the same applies to libvirt to an even greater extent.) > 6. A configuration file format is sorely needed so that guest > configuration can be persisted and easily launched. Actually qemu already has that, but it's really half-assed, barely documented, and doesn't cover major features that qemu provides :-) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
