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