Loaded question in response to https://lists.gnu.org/archive/html/qemu-devel/2015-10/msg06988.html, but posting as a new thread to call attention to it:
Libvirt uses libyajl to parse and format JSON. Would it be worth
dragging in yet another prerequisite library into qemu and reuse
libyajl's parser instead of our own hand-rolled one?
I know that a while ago, the answer was "as long as we support
out-of-the-box builds on RHEL 5, that platform lacks yajl therefore we
can't depend on it" (and libvirt's solution on RHEL 5 is "qemu doesn't
support QMP and thus doesn't use JSON and thus libvirt doesn't need yajl
there").
But now that we have just recently bumped the minimum glib and python
versions to something not available on RHEL 5, it may also be time to
start thinking about outsourcing to libyajl, because as far as I can
tell, every platform that currently supports qemu out of the box has a
version of libyajl. And since libvirt has already figured out the grunt
work of how to simultaneously code to both the 1.x and 2.x APIs, it's
not that much of a stretch to reuse that work in qemu.
On the other hand, one of the "features" of qemu's hand-rolled json
parser is the ability to do qobject_from_jsonf("{'foo':%s}", "bar")
(that is, we extended JSON with our notion of single-quoted strings, and
with our notion of %s and similar escape sequences for piecing together
multiple inputs into a single input stream without having to first
g_strdup_printf our pieces into a single string). I don't know if
libyajl lets us add extensions to the language it parses.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
