Re: [Libvir] Questions about the future of libvirt
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/