[Libvir] [PATCH] Check availability of driver calls

[Daniel Veillard]

On Tue, Aug 21, 2007 at 03:42:44AM +0100, Daniel P. Berrange wrote:
> On Mon, Aug 20, 2007 at 04:43:27PM +0100, Richard W.M. Jones wrote:
> > This doesn't work though, because different parts of the system have to 
> > answer different parts of a request such as:
> > 
> >   VIR_DRV_FEATURE_MIGRATION_V1 | VIR_DRV_FEATURE_REMOTE.
> > 
> > VIR_DRV_FEATURE_MIGRATION_V1 goes through to end driver. 
> > VIR_DRV_FEATURE_REMOTE is answered by the local end of remote 
> > (src/remote_internal.c).  My real point is I don't understand the case 
> > where it is ever useful to query more than one feature.
> 
> My first inclination was to also suggest a bitfield, but looking at the
> use case now I agree its overkill. If we did ever need to query more than
> one feature here, the roundtrip time would be dwarfed by the time to do
> the actual migration.

  Bah, if I'm in the minority that's fine, go ahead !

> > >you still pas and return an atomic value, you just need a little bit of 
> > >decoding work at the C level to analyze the bits in the values, but that's
> > >won't be much more complex than a switch based on the enum, and IMHO
> > >more reliable, because I still (sorry) consider enums in APIs to be a big
> > >problem in C. Even if it's considered an internal API, I would avoid enums
> > >there because of the RPC.
> > 
> > I meant to get rid of the enums.  Attached is a version which uses 
> > macros instead so the type should always be 'int' (ie. ABI stable).
> 
> Ok, that's fine by me.

  okay +1

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/