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

[George Dunlap <george.dunlap@eu.citrix.com>]

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