On Fri, Mar 03, 2006 at 09:39:26AM -0600, Anthony Liguori wrote:
David Anderson wrote:
This layout does not scale well, especially if the plan is to introduce support for other virtualization engines. So, I'd like to propose implementing a vtable-based interface. We define a structure of all the callback functions a backend can/must provide. Then, the open functions, depending on the URI passed in, will initialize a certain backend and let it populate the vtable with its callbacks.
I think this is a sane thing to do. My personal preference would be something more akin to how Linux handles this sort of things. Function pointers in an otherwise opaque type and backend "modules" that register themselves. We could eventually get to a place where hypervisors were supported just by adding plugins.
I agree that code refactoring is needed, but I don't want to go too far before having a second backend (hopefully I will be able to hack QEmu soon enough to build one). I'm always a bit vary of too much abstraction when the code ain't really field tested :-) . But again I totally agree that the current code must be cleaned up, it's just that I would prefer to work toward the implementation phase to then be able to take the right decisions on terms of internal abstract APIs. W.r.t. plugins, this may be a bit too far away from my taste, it's not like there is as many virtualization/emulation frameworks as hardware species supported on Linux, I would rather not make backend APIs public and instead see the code in libvirt. If someone really has a need for extending with proprietary code, it's LGPL so they can fork it legally, but with all associated duties :-) . But anyway let's first try to see if we can drive 2 engines with current APIs and it still makes any sense ;-) Daniel -- Daniel Veillard | Red Hat http://redhat.com/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/