[Libvir] [PATCH] Check availability of driver calls

[Richard W.M. Jones]

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.

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

Rich.

-- 
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom.  Registered in
England and Wales under Company Registration No. 03798903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libvirt-driver-feature-20070820-2.patch
Type: text/x-patch
Size: 8212 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070820/06e9d193/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070820/06e9d193/attachment-0003.bin>