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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list