I think it would be a good idea to make this a general pointer for the kernel to
be able to write per thread state to user space, which obviously can't be done
with the vDSO.
This means the libc per thread startup should query the kernel for the size of
this structure and allocate thread local data accordingly. We can then grow
this structure if needed without making the ABI even more complex.
This is more than a system call: this is an entirely new way for userspace to
interact with the kernel. Therefore we should make it a general facility.
I'm really glad to see I'm not the only one seeing potential for
genericity here. :-) This is exactly what I had in mind
last year when proposing the thread_local_abi() system call:
a generic way to register an extensible per-thread data structure
so the kernel can communicate with user-space and vice-versa.
Rather than having the libc query the kernel for size of the structure,
I would recommend that libc tells the kernel the size of the thread-local
ABI structure it supports. The idea here is that both the kernel and libc
need to know about the fields in that structure to allow a two-way
interaction. Fields known only by either the kernel or userspace
are useless for a given thread anyway. This way, libc could statically
define the structure.
I would be tempted to also add "features" flags, so both user-space
and the kernel could tell each other what they support: user-space
would announce the set of features it supports, and it could also
query the kernel for the set of supported features. One simple approach
would be to use a uint64_t as type for those feature flags, and
reserve the last bit for extending to future flags if we ever have
more than 64.