On 11 December 2015 at 07:12, Alexander Shishkin <alexander.shishkin@xxxxxxxxxxxxxxx> wrote: > Mathieu Poirier <mathieu.poirier@xxxxxxxxxx> writes: > >> For Coresight ETMv3/4 tracers the event carries information >> about trace modes such as user or kernel space tracing and >> whether tracing is allowed when operating in secure mode. > > Ok, so it looks to me that what you're doing in your setup_aux with the > event, you should rather be doing in pmu::event_init(), which takes > event as a parameter and it even makes more sense semantically, because > that bit is really configuring the parameters of tracing and not > capturing, which setup_aux() is more about. And the above paragraph also > sounds very much like it. Since in Coresight there is a very clear > distinction between trace generation (sources) and capturing (sinks) it > should also be possible to structure the code in such a way that the > former are not as closely tied to the latter. Please correct me if I'm > missing something. Conceptually there is no need to do the configuration for source, path and sink in setup_aux() but all this information has to be kept somewhere... Since setup_aux() is where the private data structure that will be used for the rest of the trace session gets created I didn't see another way. But with your patchset on trace filtering [1] I'm pretty sure we don't need to do tracer configuration for all the tracers at the beginning. I have to double check a few things but it is very likely that CS tracer configuration can be made the same way PT is done, something that will seriously simplify the setup process. That leaves us with the path from source to sink - it is event specific and as such needs to be part of the private data structure. Unless you see a better way to proceed it will stay in setup_aux... Thanks for the review, Mathieu [1]. https://lkml.org/lkml/2015/12/11/449 > > Regards, > -- > Alex -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
