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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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