Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752748AbbLJRAF (ORCPT ); Thu, 10 Dec 2015 12:00:05 -0500 Received: from mail.efficios.com ([78.47.125.74]:40759 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751688AbbLJRAD (ORCPT ); Thu, 10 Dec 2015 12:00:03 -0500 Date: Thu, 10 Dec 2015 16:59:58 +0000 (UTC) From: Mathieu Desnoyers To: Russell King - ARM Linux 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 , rostedt , "Paul E. McKenney" , Josh Triplett , Linus Torvalds , Andrew Morton , linux-api Message-ID: <1090286680.231411.1449766798422.JavaMail.zimbra@efficios.com> In-Reply-To: <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> <20151210162723.GN8644@n2100.arm.linux.org.uk> Subject: Re: [RFC PATCH 2/2] thread_local_abi: wire up ARM system call MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [78.47.125.74] X-Mailer: Zimbra 8.6.0_GA_1178 (ZimbraWebClient - FF42 (Linux)/8.6.0_GA_1178) Thread-Topic: thread_local_abi: wire up ARM system call Thread-Index: ua0XzQrE+nmHjlPZsau7xAnKBSQWyA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2819 Lines: 77 ----- On Dec 10, 2015, at 11:27 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote: > 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? Thomas showed interest in trying it out on ARM, which is why I'm sending this RFC patch "To" him. Of course, I plan to send it to you if it goes beyond RFC stage. > >> 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. Oops, right. Will do. > > 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.) Sounds good. Anyway please wait until I send a non-RFC patch before doing so. Thanks! Mathieu > > 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. -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com -- 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/