I think the argument you provide here for this being specific to my project is __almost__ true.

I can't really think of any other usage for the Coresight other than starting and stopping tracers.. 

The API indeed should be much more flexible and provide the user the power of choosing it's own Coresight path(from source to

sink). This will force me to do a change that is much much larger than the current change(which quite is very simple).

My aim is the simply to provide an API that will make it possible to do what perf does, only from the outside of the infrastructure.

(Notice currently perf is restricted to a single thread, and the CS_MODE_API can be used for multiple threads, e.g. a process..).

In the end i think you're right.. i might consider going further with this changeset, but like you've said you think

designing a more flexible kernel API is the right approach, although the infrastructure is not quite ready for it.

Thank you for your review.

Mike.