Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753563AbbLJQ1r (ORCPT ); Thu, 10 Dec 2015 11:27:47 -0500 Received: from pandora.arm.linux.org.uk ([78.32.30.218]:40340 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753416AbbLJQ1q (ORCPT ); Thu, 10 Dec 2015 11:27:46 -0500 Date: Thu, 10 Dec 2015 16:27:23 +0000 From: Russell King - ARM Linux To: Mathieu Desnoyers Cc: Thomas Gleixner , linux-kernel@vger.kernel.org, Catalin Marinas , Will Deacon , Paul Turner , Andrew Hunter , Peter Zijlstra , Andy Lutomirski , Andi Kleen , Dave Watson , Chris Lameter , Ingo Molnar , Ben Maurer , Steven Rostedt , "Paul E. McKenney" , Josh Triplett , Linus Torvalds , Andrew Morton , linux-api@vger.kernel.org Subject: Re: [RFC PATCH 2/2] thread_local_abi: wire up ARM system call Message-ID: <20151210162723.GN8644@n2100.arm.linux.org.uk> References: <1449761990-23525-1-git-send-email-mathieu.desnoyers@efficios.com> <1449761990-23525-2-git-send-email-mathieu.desnoyers@efficios.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1449761990-23525-2-git-send-email-mathieu.desnoyers@efficios.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2300 Lines: 54 On Thu, Dec 10, 2015 at 10:39:50AM -0500, Mathieu Desnoyers wrote: > Wire up the thread local ABI on ARM32. Call the > getcpu_cache_handle_notify_resume() function on return to userspace if > TIF_NOTIFY_RESUME thread flag is set. > > This provides a way to implement a sched_getcpu() on ARM without > requiring to perform a system call on the fast path. > > [ Untested. ] Why are you sending this _to_ Thomas? Shouldn't you be sending it to me as the arch maintainer? > diff --git a/arch/arm/include/asm/unistd.h b/arch/arm/include/asm/unistd.h > index 7b84657..ef55382 100644 > --- a/arch/arm/include/asm/unistd.h > +++ b/arch/arm/include/asm/unistd.h > @@ -19,7 +19,7 @@ > * This may need to be greater than __NR_last_syscall+1 in order to > * account for the padding in the syscall table > */ > -#define __NR_syscalls (392) > +#define __NR_syscalls (393) That will cause a build error. Please leave this alone until we get to syscall 392, where upon it will need to be incremented by four. Also, I tend to wait until after -rc1 before adding any syscalls, when all the new syscalls are obvious and known - this avoids ending up with two different trees having allocated the same syscall number (which is why arch maintainers should be the only people who are responsible for merging updates to their arch's syscall numbering.) Sure, if multiple different people end up merging patches via different routes, the conflicts can be resolved when those different routes come together, but what happens if someone adds the syscall number that they thought they had to (eg) glibc, and then have to change it later because come -rc1 it ends up being different... I'd much rather that all patches to unistd.h are only mergable via the respective arch maintainers to keep the numbering sane. (I personally want to follow x86's syscall numbering order as much as possible.) -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/