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


[Xen-devel] Re: [patch 2/8] Implement always-locked bit ops, for memory

To: Christoph Lameter <clameter@xxxxxxx>
Subject: [Xen-devel] Re: [patch 2/8] Implement always-locked bit ops, for memory shared with an SMP hypervisor.
From: Andi Kleen <ak@xxxxxxx>
Date: Thu, 3 Aug 2006 07:25:13 +0200
Cc: akpm@xxxxxxxx, Jeremy Fitzhardinge <jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Ian Pratt <ian.pratt@xxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, Chris Wright <chrisw@xxxxxxxxxxxx>, virtualization@xxxxxxxxxxxxxx
Delivery-date: Wed, 02 Aug 2006 22:25:42 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <Pine.LNX.4.64.0608022213530.26980@xxxxxxxxxxxxxxxxxxxxxxxxx>
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>
References: <20060803002510.634721860@xxxxxxxxxxxxx> <200608030649.11452.ak@xxxxxxx> <Pine.LNX.4.64.0608022213530.26980@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.3
> As far as I can tell from this conversation there are special "Xen" 
> drivers that need this not the rest of the system.

Yes, but in general when a driver that runs on multiple architectures
(including IA64 btw) needs something architecture specific we usually
add it to asm, not add ifdefs.
> > > for those special xen drivers.
> > 
> > Well there might be reasons someone else uses this in the future too.
> > It's also not exactly Linux style - normally we try to add generic
> > facilities.
> What possible use could there be to someone else?

e.g. for other hypervisors or possibly for special hardware access
(e.g. I could imagine it being used for some kind of cluster interconnect)
I remember Alan was using a similar hack in his EDAC drivers because
it was the only way to clear ECC errors. 

> The "atomic" ops lock/unlock crap exists only for i386 as far as I can 
> tell. As you said most architectures either always use atomic ops or 
> never. The lock/unlock atomic ops are i386 specific material that 
> better stay contained. Its arch specific and not generic.

Well we have our share of weird hacks for IA64 too in generic code.

Just adding a single line #include for a wrapper asm-generic surely isn't
a undue burden for the other architectures, and it will save some
mess in the Xen drivers.


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>