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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/