On Tue, Apr 05, 2016 at 06:02:25PM +0200, Florian Weimer wrote: > On 04/04/2016 10:48 PM, Mathieu Desnoyers wrote: > > > Moreover, the feature set that the application knows about, glibc > > knows about, and the kernel knows about are three different things. > > My intent here is to have glibc stay out of the way as much as possible, > > since this is really an interface between various applications/libraries > > and the kernel. > > Surely glibc can allocate the space based on what is advertised as > needed by the kernel? Why would it limit itself to what is supported by > the kernel headers it is compiled against if the actual size can be > queried from the kernel? I guess the question is; can we do thread local variable arrays like: __thread uint32_t[x]; /* with x being a runtime constant */ Because then we can do: __thread struct thread_local_abi tla; where sizeof(struct thread_local_abi) is a runtime variable. Without that we cannot have this thread-local-abi structure be part of the immediately addressable TLS space. That is, we then need a pointer like: __thread struct thread_local_abi *tla; and every usage will need the extra pointer deref. Because ideally this structure would be part of the initial (glibc) TCB with fixed offset etc. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
