On 31 March 2016 at 03:43, Ola Liljedahl Ola.Liljedahl@arm.com wrote:
On 30/03/2016, 22:58, "CoreSight on behalf of Mathieu Poirier" <coresight-bounces@lists.linaro.org on behalf of mathieu.poirier@linaro.org> wrote:
On 30 March 2016 at 11:08, Al Grant Al.Grant@arm.com wrote:
Hi,
I'd like to get your thoughts on an appropriate low-level userspace API for STM. The API I'm after would assume the ability to map a range of channels into userspace as detailed in Documentation/trace/stm.txt:
"Some STM devices may allow direct mapping of the channel mmio region to userspace for zero-copy writing..."
What that doesn't describe is what you do with the region once you've got it. Which suggests a userspace API that can abstract over the way channels are represented in the memory map, i.e. how bits of the address are used to influence the data packets. Given a channel number (or a relative channel number) and some data, it would generate a store to the right address, or an lvalue at the right address. So you could write something like this:
STM_TRACE_DATA(p, TIMESTAMP, uint32, 123);
or perhaps
*STM_TRACE_CHANNEL(p, TIMESTAMP, uint32) = 123;
and this would become inline code that would be a single store that would cause a D32 packet. The ARM and Intel implementations would differ in how they calculated the address and perhaps on whether some features were available. 64-bit writes would be unavailable on some ARM systems.
Userspace libraries that implemented higher-level messaging formats could then sit on top of this lower-level API.
I don't think I've seen this in any of the patches that have come round but is anyone working on anything like this?
Good afternoon,
Nobody is working a user space API that would do something like that nor do I personally have plan for the team to do so. Aside from a few exception (like the openCSD project) Linaro's activities are mainly focused on the kernel.
Meaning what? Tracing from the kernel only? Or CoreSight tracing as an OS/kernel service to applications through a system call interface? Or?
Meaning that we focus on providing solutions that are confined to kernel space. User space is a completely different realm that we try to avoid due to the large spectrum it covers. We got involved in the openCSD project because without an open source decoding solution, the kernel driver stack is useless.
We simply don't have the resources and the use cases to get involved in user space. Our goal is to bring things forward to a point where people can start using them to build product or solve problems. The drivers can expose interfaces to user space but we won't get involved in how those interface are get used.
Mathieu
‹ Ola
That being said I never thought of this team as an autocracy - if someone wants to work on this I'll be happy to help draft the card.
Regards, Mathieu
Al
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight