[Libvir] Questions about the future of libvirt

[Daniel Veillard]

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