----- On Feb 27, 2016, at 7:57 PM, Linus Torvalds torvalds@xxxxxxxxxxxxxxxxxxxx wrote:
> On Sat, Feb 27, 2016 at 4:39 PM, Mathieu Desnoyers
> <mathieu.desnoyers@xxxxxxxxxxxx> 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
--
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
