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