From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757924AbcB1Ocm (ORCPT ); Sun, 28 Feb 2016 09:32:42 -0500 Received: from mail.efficios.com ([78.47.125.74]:58666 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757419AbcB1Ock (ORCPT ); Sun, 28 Feb 2016 09:32:40 -0500 Date: Sun, 28 Feb 2016 14:32:28 +0000 (UTC) From: Mathieu Desnoyers To: Linus Torvalds Cc: Ben Maurer , Thomas Gleixner , Ingo Molnar , Russell King , linux-api , Andrew Morton , Michael Kerrisk , Dave Watson , rostedt , Andy Lutomirski , Will Deacon , "Paul E. McKenney" , Chris Lameter , Andi Kleen , Josh Triplett , Paul Turner , Linux Kernel Mailing List , Catalin Marinas , Andrew Hunter , "H. Peter Anvin" , Peter Zijlstra Message-ID: <1538518747.10504.1456669948568.JavaMail.zimbra@efficios.com> In-Reply-To: References: <1456270120-7560-1-git-send-email-mathieu.desnoyers@efficios.com> <2053850250.10158.1456582501604.JavaMail.zimbra@efficios.com> <20160227145809.GD6356@twins.programming.kicks-ass.net> <1401667361.10273.1456617236327.JavaMail.zimbra@efficios.com> <1082926946.10326.1456619994590.JavaMail.zimbra@efficios.com> Subject: Re: [PATCH v4 1/5] getcpu_cache system call: cache CPU number of running thread 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 - FF44 (Linux)/8.6.0_GA_1178) Thread-Topic: getcpu_cache system call: cache CPU number of running thread Thread-Index: bKdBkBtcQBk0XABM5wyoqBgOEQmrHg== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Feb 27, 2016, at 7:57 PM, Linus Torvalds torvalds@linux-foundation.org wrote: > On Sat, Feb 27, 2016 at 4:39 PM, Mathieu Desnoyers > wrote: >> >> >> I'm particularly interested to know what are the best practices to >> deal with an extensible bitfield (the features mask). cpu_set_t >> and sigmask each seem to do their own thing. > > Quite frankly, why would the kernel ever touch anything else? > > And if the kernel doesn't touch anything else, why make it part of the ABI? > > I don't see why the kernel would ever want to have a more complex > interface. Explain. The part of ABI I'm trying to express here is for discoverability of available features by user-space. For instance, a kernel could be configured with "CONFIG_RSEQ=n", and userspace should not rely on the rseq fields of the thread-local ABI in that case. The initial idea I had was to populate a mask of available features (hence my question above), but now that I think about it, we could perhaps have a "query" system call receiving a "feature number", no mask needed then. E.g.: enum thread_local_abi_features { THREAD_LOCAL_FEATURE_CPU_ID = 0, THREAD_LOCAL_FEATURE_RSEQ = 1, /* Add future features here. */ }; int thread_local_abi_feature(uint64_t feature); Another option would be to rely on specific "uninitialized" values for each feature in struct thread_local_abi (e.g. -1 for cpu_id). We may need to reserve extra space for "feature enabled" booleans in cases where the uninitialized value is also used when initialized (e.g. a sequence counteR). The advantage of using the uninitialized value and/or the "boolean" within the struct thread_local_abi is that testing whether the feature is active can be done by reading from the same cache-line as when using the feature (in user-space). Not sure what would be the best option here. Thoughts ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com