On 27 May 2011 10:45, Arnd Bergmann arnd@arndb.de wrote:
On Thursday 26 May 2011, Philippe Langlais wrote:
I initiate the work to build a hardware trace framework in the kernel,
I'm
not started the study to have a common userspace API for STM, thanks to this email we can start
such
a work, but it may be long (next week I'm in vacation till June 7th).
I missed the initial parts of the conversation, but I think that regarding the user interface, the most important issue by far is integration into the perf events infrastructure. There is no room for having yet another API to get at tracing and performance data.
I think that we misunderstood each other on the purpose of STM to particularly on the term "hardware trace": For more information see http://www.arm.com/products/system-ip/debug-trace/trace-macrocells-etm/cores... . This new user API is to manage trace resources (channels) and configuration of STM for the rest it's standard write only char driver to provide printf style debug interface. There is no interference with perf event infrastructure.
See my detailed response for all your interrogations and my thoughts
about
STE STM implementation below:
On 25 May 2011 23:54, Deao, Douglas d-deao@ti.com wrote:
Sorry it took a while to get back to you guys. I was visiting customers last week. Most of my comments are just highlighting the differences
between
TI's STM 1.0 driver and ST-E's STM 1.0 driver, but there are a few questions, observations and suggestions. At the end I included some discussion on TI's meta data and OST header requirements.
I have not had a chance to look at your actual implementation yet. Did
you
do anything to abstract the actual HW transport ports and control
registers
from the higher level driver functions?
Yes, partially I think through IOCTLs & debugfs (see our stm.h userspace API)
Any ioctls in addition to the ones defined in include/linux/perf_event.h will need to be coordinated with the perf developers.
Regarding a debugfs interface, you need to consider that all you cannot build stable interfaces in debugfs by definition. If you want to have long-term support for your subsystem, you would need a new file system.
OK
I am especially interested in details of what you guys have in mind for
a
"common trace framework to receive STM drivers". If by framework you
mean
well defined APIs that are implemented for specific devices, then I
think we
are in agreement. What Michael and I have talked about is a common STM
user
mode experience across all Linaro supported devices, making Linux user
mode
code 100% portable between our devices.
For my point of view, the trace device framework must ease the
integration
of new hardware trace drivers in the kernel (not only STM MIPI) to present standard hooks in current trace infrastructure, but it can cover a common STM userspace API too.
Can you explain the difference between hardware trace drivers and PMU drivers? What does the common infrastructure for trace drivers do that is not already handled by ftrace or perf?
STM is more an hardware to extract printf like traces and far less intrusive, it can be use instead of internal trace ring buffer to extract ftrace or perf results through an external probe.
I am thinking that for each unique pid a channel should be assigned
when
the device is opened. I would guess you are keeping a channel table
around
and write() just checks the table for a pid assignment (no time to look
at
your implementation yet), if none is found the first free channel is
used.
If you moved this function back to open then you could do the IOCTL STM_GET_CHANNEL_NO anytime, not just after the first write.
The reason behind this behavior is for our current STM user lib which
open
"/dev/stm" and alloc/free channels with IOCTL and never use write operation (only mmap + direct write) and in
this
case we don't want to loose a channel. I think we can change this behavior. We can support multiple channels allocated for one Process to avoid contention in multi-threaded process.
/dev/stm does not sound particularly hardware independent, i.e. it would not be portable to other architectures. The kernel interface should realy abstract such differences. Why do you need an extra character device besides the perf file descriptor?
Arnd
Philippe