[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 11/14] libxl: get and set soft affinity



On 20/11/13 11:40, Dario Faggioli wrote:
On mer, 2013-11-20 at 11:32 +0000, Ian Campbell wrote:
On Wed, 2013-11-20 at 11:29 +0000, George Dunlap wrote:
On 20/11/13 11:27, Ian Campbell wrote:
I did actually check and, of all the enum-s in the IDL, none are used as
flags, they're rather used as "single values". OTOH, the only actual
flags I found (I think it was LIBXL_SUSPEND_DEBUG, LIBXL_SUSPEND_LIVE)
were defined like I did myself above... That's why I went for it.
I have a feeling they predate the IDL, or at least the Enumeration
support. It's true that we don't have any other bit fields in enums
though. I can't see the harm, it's probably not worth introducing a new
IDL type for them.
Since these are bits, not numbers, I don't think an enum is the right
construct.  Or, the enum values should be the *bit numbers*, and the
flags should be (1<<[bit_humber]).
That would need a new IDL type to express. In which case lets just leave
the raw #defines, unless anyone else has a strong opinion.

That would probably the best option, at least for now. Of course, I can
add "introduce a new IDL type for bitfields" to my TODO list, and send a
followup patch for 4.5.

But if we end up doing as IanC suggests -- having a new function which accepts two pointers, either of which can be NULL -- then the need for these OR-able flags goes away, doesn't it?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.