From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: PTE access rules & abstraction From: Benjamin Herrenschmidt Reply-To: benh@kernel.crashing.org In-Reply-To: <48DBD532.80607@goop.org> References: <1221846139.8077.25.camel@pasglop> <48D739B2.1050202@goop.org> <1222117551.12085.39.camel@pasglop> <1222291248.8277.90.camel@pasglop> <1222304686.8277.136.camel@pasglop> <48DBD532.80607@goop.org> Content-Type: text/plain Date: Fri, 26 Sep 2008 07:44:23 +1000 Message-Id: <1222379063.8277.202.camel@pasglop> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Jeremy Fitzhardinge Cc: Hugh Dickins , Linux Memory Management List , Linux Kernel list , Nick Piggin , Martin Schwidefsky List-ID: On Thu, 2008-09-25 at 11:15 -0700, Jeremy Fitzhardinge wrote: > The ptep_modify_prot_start/commit pair specifies a single pte update in > such a way to allow more implementation flexibility - ie, there's no > naked requirement for an atomic fetch-and-clear operation. I chose the > transaction-like terminology to emphasize that the start/commit > functions must be strictly paired; there's no way to fail or abort the > "transaction". A whole group of those start/commit pairs can be batched > together without affecting their semantics. I still can't see the point of having now 3 functions instead of just one such as ptep_modify_protection(). I don't see what it buys you other than adding gratuituous new interfaces. Ben;. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org