My only suggestion is that we could put the strings into a separate ELF section to make them easy to pull out of the binary. One of our libguestfs contributors did this for the libguestfs daemon so that it's possible now to examine the daemon and find out what binaries it runs/requires. He did it using the following macro: #define __external_command __attribute__((__section__(".guestfsd_ext_cmds"))) #define GUESTFSD_EXT_CMD(___ext_cmd_var, ___ext_cmd_str) static const char ___ext_cmd_var[] __external_command = #___ext_cmd_str OpenSUSE's spec file has a section to read out the commands and produce dependencies. It uses objcopy to read out the commands from the binary: objcopy -j .guestfsd_ext_cmds -O binary $RPM_BUILD_ROOT/usr/sbin/guestfsd /dev/stdout | tr '\0' '\n' | sort -u

Oooh, that's an interesting approach. It will tell you too much, in so much that it wouldn't be possible to see that a number of commands are supported by libvirt, but won't be used with specific QEMU version. But just having an automated way to extract this full list would still be pretty useful info. Since, we'd be able to automatically detect additions between releases. So I guess we could take our current code: virJSONValuePtr cmd = qemuMonitorJSONMakeCommand("query-block", NULL); and change it to QEMU_JSON_CMD(QUERY_BLOCK, "query-block"); ... virJSONValuePtr cmd = qemuMonitorJSONMakeCommand(QEMU_JSON_CMD_QUERY_BLOCK, NULL); with QEMU_JSON_CMD being a macro you use in global context to define a string constant + the elf section.

virJSONValuePtr cmd = qemuMonitorJSONMakeCommand(QEMU_JSON_CMD("query-block"), NULL);