[libvirt] Using magic ELF notes to export info about QEMU monitor commands

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 :|
participants (1)
-
Daniel P. Berrange