On Thu, Feb 21, 2008 at 02:36:10PM +0000, Daniel P. Berrange wrote:
- Else probe each registered driver in order until one succeeds
For the latter I think we could add a 'probe' method to the internal driver
API table. Then we can just call 'probe' on each driver in turn until we
find one which is available on the system.
At the same time it could be worth having a public API to 'detect drivers'
which will call probe for each driver and return a list of all drivers
which are available. This allows an app to easily ask libvirt what it
supports
I actually started to look at that and while it sounds good 'on paper'
it's a bit messy in practice, for example:
- test driver: if compiled in, you would think the probe should return
true, but as a result if trying an operation whyle no hypervisor
is available you would end up doing it on the test driver instead of
returning a failure, annoying
- qemu driver: well QEmu is actually a driver for a potentially large
set, KVM, QEmu for the current architecture, QEmu for emulated
architectures. Would the probe return true if it finds
/usr/bin/qemu-mips ? Or the KVM package may be present but would not be
usable because the current kernel doesn't have a kvm module
Trying to be a bit systematic purely based on the driver model proves harder
than expected, still worth trying but I prefer early feedback :-)
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/