Re: [libvirt] [PATCH for 1.2.7 1/8] Introduce domain_capabilities

I was trying to envision use cases - that is how is this expected to be used and what "knowledge" is assumed of the caller/user vs. being designed to a more naive user trying to glean information about what's available. You have a very specific use case described - can I determine if vfio is supported, but that requires someone knowing quite a bit of information that isn't easily accessible unless you read sources or have a bit of history built up. For the domcapabilities command that eventually gets added - how does one know what to provide for the 4 options without knowing a bit about the environment. It seems the assumption is the user knows to pass certain elements. The 'virttype' is pretty easy - that comes from the connection - so I wonder why it's a parameter to be provided. Does one really have to have a connection to get the data? The 'emulatorbin' is less obvious. If it's not passed, there is a way to get the default value given that you have a virttype, an os type, and an os arch using virCapabilitiesDefaultGuestEmulator(). What if someone provides "/usr/bin/qemu-kvm" or "/usr/libexec/qemu-kvm" or is there an expectation of /usr/bin/qemu-system-x86_64? The 'arch' requires a bit more knowledge, but is certainly "obtainable" as a default by the current host arch, right? There's also virCapabilitiesDefaultGuestArch(). However, if someone was looking to find out what was running on the remote connection (not the local machine), then that assumption would be incorrect. Seems we should be able to figure out what arch is associated with the connection. I think 'machine' is perhaps the most odd to provide; however, like arch and emulatorbin, there is virCapabilitiesDefaultGuestMachine() to help you out. For this if one passed "pc" does that work - or do they have to pass something like "pc-i440fx-1.6" with the next question being how would they know to generate that?