From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH] fix xenctl_cpumap translation to handle bitops accessed like arrays Date: Mon, 18 Dec 2006 17:55:59 +0000 Message-ID: References: <31010730-4AB4-48CA-BA8D-F281E6B4C9FC@watson.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <31010730-4AB4-48CA-BA8D-F281E6B4C9FC@watson.ibm.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jimi Xenidis , Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 18/12/06 16:50, "Jimi Xenidis" wrote: >> another >> a uint64_t. Perhaps we should fix so they pass down 8-bit units (as >> the type >> of xenctl_cpumap_t would suggest) and then we could have >> byte_to_long_bitmap >> and long_to_byte_bitmap in Xen > > Are you suggesting to still use bits in the bytes? > If so, then do you want "C" ordering in the byte or arch bit ordering? > Perhaps we simply to us the byte array as a list of CPU numbers, with > -1 to terminate? I mean bits 8k to 8k+7 inclusive are contained in byte at offset k in the cpumap, and in the obvious order (8k is least significant bit; 8k+7 is most significant). This is the byte-oriented bitmap type that your bitops.h goes on about. Since xenctl_cpumap_t is defined as a byte array and byte count, this interpretation would make sense. -- Keir