From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH v3 11/14] libxl: get and set soft affinity Date: Wed, 20 Nov 2013 14:45:53 +0000 Message-ID: <528CCB21.4040200@eu.citrix.com> References: <20131118175544.31002.79574.stgit@Solace> <20131118181813.31002.61195.stgit@Solace> <1384881864.16252.48.camel@hastur.hellion.org.uk> <1384883478.19880.170.camel@Abyss> <1384946825.28441.56.camel@kazak.uk.xensource.com> <528C9D0D.8020302@eu.citrix.com> <1384947125.28441.60.camel@kazak.uk.xensource.com> <1384947634.15360.52.camel@Solace> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1384947634.15360.52.camel@Solace> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli , Ian Campbell Cc: Marcus Granado , Keir Fraser , Matt Wilson , Li Yechen , Andrew Cooper , Juergen Gross , Ian Jackson , xen-devel@lists.xen.org, Jan Beulich , Justin Weaver , Elena Ufimtseva List-Id: xen-devel@lists.xenproject.org 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