[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [Libvir] virDomainDump() API (equivalent to xm dump) in libvirt?
- From: Daniel Veillard <veillard redhat com>
- To: Karel Zak <kzak redhat com>
- Cc: libvir-list redhat com
- Subject: Re: [Libvir] virDomainDump() API (equivalent to xm dump) in libvirt?
- Date: Thu, 9 Nov 2006 06:20:59 -0500
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/
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]