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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list