On another mailing list some folks were discussing how to determine what list of QEMU monitor commands a particular libvirt was written to be able to use. Rich Jones mentioned a thing they are doing in libguestfs using magic ELF notes: > 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 To which I replied > 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. ----- End forwarded message ----- In fact it would be preferable if you could just do it inline > virJSONValuePtr cmd = qemuMonitorJSONMakeCommand(QEMU_JSON_CMD("query-block"), > NULL); > instead of having the macro call separate, but it isn't clear that you can define ELF sections from inline code like that. Anyway, I'm not planning to implement this, but I wanted to mention this idea in case if motivates anyone else here to have a go at writing this feature idea.... Regards, Daniel; -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list