----- On Dec 10, 2015, at 11:27 AM, Russell King - ARM Linux li...@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-api" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
