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(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/