From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from science.horizon.com ([192.35.100.1]:15915 "HELO science.horizon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1759658AbWLKCa4 (ORCPT ); Sun, 10 Dec 2006 21:30:56 -0500 Date: 10 Dec 2006 21:30:54 -0500 Message-ID: <20061211023054.2622.qmail@science.horizon.com> From: linux@horizon.com Subject: Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an Sender: linux-arch-owner@vger.kernel.org To: nickpiggin@yahoo.com.au, torvalds@osdl.org Cc: linux@horizon.com, linux-arch@vger.kernel.org, linux-arm-kernel@lists.arm.linux.org.uk, linux-kernel@vger.kernel.org List-ID: > Even if ARM is able to handle any arbitrary C code between the > "load locked" and store conditional API, other architectures can not > by definition. Maybe so, but I think you and Linus are missing the middle ground. While I agree that LL/SC can't be part of the kernel API for people to get arbitrarily clever with in the device driver du jour, they are *very* nice abstractions for shrinking the arch-specific code size. The semantics are widely enough shared that it's quite possible in practice to write a good set of atomic primitives in terms of LL/SC and then let most architectures define LL/SC and simply #include the generic atomic op implementations. If there's a restriction that would pessimize the generic implementation, that function can be implemented specially for that arch. Then implementing things like backoff on contention can involve writing a whole lot less duplicated code. Just like you can write a set of helpers for, say, CPUs with physically addressed caches, even though the "real" API has to be able to handle the virtually addressed ones, you can write a nice set of helpers for machines with sane LL/SC.