* Marco Elver elver@google.com wrote:
Yeah, so why cannot we allocate enough space from the signal handler user-space stack and put the attr there, and point to it from sig_info?
The idea would be to create a stable, per-signal snapshot of whatever the perf_attr state is at the moment the event happens and the signal is generated - which is roughly what user-space wants, right?
I certainly couldn't say how feasible this is. Is there infrastructure in place to do this? Or do we have to introduce support for stashing things on the signal stack?
From what we can tell, the most flexible option though appears to be just some user settable opaque data in perf_event_attr, that is copied to siginfo. It'd allow user space to store a pointer or a hash/key, or just encode the relevant information it wants; but could also go further, and add information beyond perf_event_attr, such as things like a signal receiver filter (e.g. task ID or set of threads which should process the signal etc.).
So if there's no strong objection to the additional field in perf_event_attr, I think it'll give us the simplest and most flexible option.
Sounds good to me - it's also probably measurably faster than copying the not-so-small-anymore perf_attr structure.
Thanks,
Ingo