Hello,
> Patches are always welcomed and I don't think there is an "easy" way
> to get out of this one. What you want to do will probably end up
> being fairly complex. I would start by closely understanding how
> operation of the CS infrastructure is done from the perf interface
> you should be find just sticking to the kernel part. There
> reservation of a "path" and memory for the sink is done in preparatory
> steps where it is permitted to sleep (non-atomic). After that
> components can be enabled from an atomic context, i.e when the process
> of interest is installed on a processor. Currently things are woven
> with the perf_aux_output_[begin|end]() interface but that could easily
> be decoupled.
> On the aspect of trace collection, did you envision using the entries
> in devFS? If that is the case a mechanism to correlate tracer
> configuration and trace data will need to be developed, just like what
> we did for perf.
> Taking a step back, tracers can also be found on X86 and MIPs (if I'm
> not mistaking) architectures. As such the new kernel API would have
> to be usable by those as well, which complicates the task even
> further.
> So all that being said I think it is feasible, but be prepared to
> invest a significant amount of time and effort.
The "generic" tracing kernel API is a different thing. In it's Coresight implementation it will use the kernel API I need.
After taking a few days to understand how the infrastructure works, to make the API as flexible as it can be, I thought about this:
Just like there's a perf implementation and a sysfs implementation, the "api" implementation(coresight-api) will be introduced, which will also be
a new mode(CS_MODE_API).
I propose these APIs(some of them exist, but need to be exported and changed a little):
* coresight_build_path(struct coresight_device *source, struct coresight_device *sink):
Create a coresight path from the provided source and sink,.
* coresight_enable_path(struct coresight_path *path):
Enable a Coresight path except the source. This will
also glue a source to a specific path. You cannot assign a different path to this source until the path is destroyed.
* coresight_disable_path(struct coresight_path *path)
Disable the path to the sink, including the sink.(if there is more than 1 path to the same sink, does not disable the sink until a refcount reaches 0).
* coresight_destroy_path(struct coresight_path *path):
Frees the path, releases the source from that path. The source device can be assigned to a different path.
* coresight_enable_source(struct coresight_device *source);
Enables the source. This will actually make the source device play the actual trace data in to the sink(i.e. etm4_enable_hw(), or, increase a refcount if
the source is already playing). Uses the path assigned in "coresight_enable_sink()".
* coresight_disable_source(struct coresight_device *source);
Disables the source. This will stop the source from playing trace data(or, if the refcount > 0, decrease the refcount).
Uses the path assigned in "coresight_enable_sink()".
* coresight_read_sink(struct coresight_device *sink, void *buf, size_t size);
Read trace data from the sink(advance the read pointer).
* coresight_setup_sink_buffer(struct coresight_device *sink, void *pages, int nr_pages);
Allocate a sink buffer(similar to the perf functionality)
The sysfs and api modes will use different buffers to avoid collision.
I realize most of the API is actually making the internal coresight implementation "public", but I really think this is necessary. Building a path to a specific sink
is something a user would want to do, as well as disabling and enabling the path whenever he wishes(this is something I actually need).
In order to use this API, the user needs a method of getting the actual (struct coresight_device *). There will be a list of coresight devices
exported in the "coresight.h" header, which can be iterated using a macro "foreach_coresight_device()". The user will be able to extract a specific
sink and source for his needs.
I think this API is powerful, and will give the user full Coresight functionality. From diving into the code, this seems very possible,
and will not require major infrastructure changes.
I will appreciate your thoughts, tips, and hints.
Thanks, Mike.