On Thu, Nov 09, 2006 at 11:32:41AM +0100, Karel Zak wrote:
On Fri, Nov 03, 2006 at 10:53:57AM -0500, Daniel Veillard wrote:
Okay I can see how this would be useful, the questions I would have would be: - how generic is this, i.e. suppose a different hypervisor back-end would this still make sense. I guess yes, for example with an UML back-end we could check the process status and force a dump with a signal and move the core to the given file not trivial but same semantic would be doable.
Is there any policy what should be included in the library? I think we will see many virtualization projects and an intersection between all projects could be very small. From my point of view include to the library something less generic is not big problem if we provide API with a "non-implemented" (ENOSYS) return codes.
A very specific API is in my experience a wrong one, you end up accumulating specific APIs instead of finding the right one which expose a good semantic. Please forget about "an integer specific return code is good enough" we clearly aren't following that path, c.f. http://libvirt.org/errors.html raising unavailable errors is a good point though. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/