[Libvir] [PATCH] Check availability of driver calls

[Daniel P. Berrange]

On Mon, Aug 20, 2007 at 04:43:27PM +0100, Richard W.M. Jones wrote:
> Daniel Veillard wrote:
> >On Mon, Aug 20, 2007 at 03:13:34PM +0100, Richard W.M. Jones wrote:
> >>This is a repost of a patch I sent before which adds the ability to 
> >>check for driver features.  This is completely internal to libvirt and 
> >>does not add any public APIs.
> >>
> >>The original discussion is here:
> >>https://www.redhat.com/archives/libvir-list/2007-July/thread.html#00437
> >>and continues here:
> >>https://www.redhat.com/archives/libvir-list/2007-August/thread.html#00000
> >>
> >>Daniel Veillard said:
> >>>>+typedef int
> >>>>+    (*virDrvSupportsFeature) (virConnectPtr conn, virDrvFeature 
> >>feature);
> >>>I would rather use , int features) where you OR the features, allows
> >>>to know in one call if you get what you want or not.
> >>My objection to that is here:
> >>https://www.redhat.com/archives/libvir-list/2007-August/msg00000.html
> >
> >  The complexity comes if you think you need to return an array of integer.
> >I guess if you just consider passing an unsigned long in and back, filled
> >as an OR'ed bitfiled with the set of features you ask for you do 1 round 
> >trip
> 
> 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.


> >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.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|