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.

> 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.

> > 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?

> > 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