This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] xen: Split domain_fla

To: Hollis Blanchard <hollisb@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [Xen-changelog] [xen-unstable] xen: Split domain_flags into discrete first-class fields in the
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Thu, 05 Apr 2007 17:59:22 +0100
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, xen-ppc-devel <xen-ppc-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 05 Apr 2007 09:58:26 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C23ADAC6.CDFE%keir@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acd3mv5kPSFhWeOOEdugmwAX8io7RQACMOH4
Thread-topic: [Xen-devel] Re: [Xen-changelog] [xen-unstable] xen: Split domain_flags into discrete first-class fields in the
User-agent: Microsoft-Entourage/
On 5/4/07 16:56, "Keir Fraser" <keir@xxxxxxxxxxxxx> wrote:

> On 5/4/07 16:44, "Hollis Blanchard" <hollisb@xxxxxxxxxx> wrote:
>> This is an interface problem: using the interface in a way that works on
>> x86 fails on other architectures. PLEASE let's redefine the interface to
>> prevent this from happening. In this case, that means replacing the
>> xchg() macro with
>>         static inline xchg(atomic_t *ptr, atomic_t val)
>> and changing the type of 'is_dying'.
> Just need to define bool_t appropriately. What do you need: a long?

Does PowerPC support atomic byte loads and stores by the way (i.e.,
concurrent loads and stores to adjacent bytes by different processors do not
conflict with each other)? In which case it might be worth keeping bool_t
and defining atomic_bool_t or atomic_rmw_bool_t for bools that need to be
atomically read-modified-written. That would avoid bloating critical
structures for the few bools that need atomic r-m-w semantics.

 -- Keir

Xen-devel mailing list