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