On 08.05.14 20:23:44, Borislav Petkov wrote: > On Wed, May 07, 2014 at 06:44:07PM +0200, Robert Richter wrote: > > With transparently I mean that the process even does not know that the > > same event is already running by another process. The kernel detects > > this and maps the request to that event and buffer. Of course the > > event's buffer must be at least readonly to be shared for this. > > Yes. > > > This could be a mechanism to connect to persistent events. The kernel > > detects by type and attr that the requested event is already running > > persistent and maps to it. > > > > But at the moment persistent events can only be shared using > > > > attr.type = PERF_TYPE_PERSISTENT > > attr.config = id > > > > So the above is more an alternative to connect to persistent events > > and the question is, which one to use. Presumable the easiest first, > > which is the current implementation. > > Well, there is no trivial way to share event buffers if they're not > read-only AFAICT. > > But in questions like this, we always have to step one step back and ask > ourselves: what are the use cases for shared events and after we have > enumerated them, to design the kernel side so that it supports them. > > So, do we want anything else besides shared, read-only events?
I only talk about events that are sharable since they are read-only. The question I am asking here is how to connect to an event that is sharable. This could be done transparently. -Robert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
