On 31/07/20 17:07, Daniel P. Berrangé wrote: > The QAPI JSON-but-not file format is a case where I think we should just > adopt a standard file format no matter what. A conversion will have some > short term work, but this is really simple data to deal with and the code > involved is nicely self contained. Again I'm not saying QAPI maintainers > must do it, just put the idea out there as a piece of work that would > be welcomed if someone is interested in working ont.
The main issues with JSON-but-not in QEMU are: - the 64-bit integers, which does not apply to the QAPI schema though - the comments, which are a common extension to JSON (see JSON5, NodeJS config files, json_verify's -c option, etc.) so I find it quite surprising that no off-the-shelf Python component can parse JSON + comments - the single-quote strings, which are not particularly useful in QAPI schema If we changed the single-quote strings to double-quote, jsonc.vim (https://github.com/neoclide/jsonc.vim) seems to support JSON + comments. In Emacs you'd probably add an epilogue like (defconst json-mode-comments-re (rx (group "#" (zero-or-more nonl) line-end))) (push (list json-mode-comments-re 1 font-lock-comment-face) json-font-lock-keywords-1) Did I miss anything? Besides that, why are we using Python and not JavaScript in the mode line? > Another example would be elimination of anything in QEMU code that is > duplicating functionality in GLib, even if there zero functional > difference between the two impls. Would you consider intrusive lists vs. GList/GSList to be duplicating functionality? I don't think we have that many duplicates at this point. We have qemu_strto*, but unfortunately the GLib function g_ascii_strtoll does nothing to fix the awful design of the C standard strto* functions (especially the overloading of the return value for error and result). If there are cases that are clear cut against adopting the GLib version, I think patches would be easily accepted. > Another example would be adopting a standard code style and using a > tool like clang-format to enforce this for entire of existing code > base and future contributions and throwing away our checkpatch.pl > which nearly everyone is scared of touching as it is Perl code. Checkpatch does much more than that, though the scary part is indeed the one that enfoces coding style. I wouldn't have a problem with using clang-format and calling it a day. Paolo