CoreSight framework and drivers

[Will Deacon]

On Wed, Jan 16, 2013 at 12:14:59AM +0000, Pratik Patel wrote:
> On Mon, Jan 07, 2013 at 11:58:36AM +0000, Will Deacon wrote:
> > On Thu, Jan 03, 2013 at 06:06:43PM +0000, Pratik Patel wrote:
> > > Whats the advantage in using debugfs here?
> > 
> > The main things I like about debugfs are (a) it's a text-driven interface
> > and easy to script with and (b) it matches what we do for ftrace.
> > 
> > Furthermore, it means that subtle differences between devices can be hidden
> > in the driver and not require different vendor tools for parsing the trace
> > data.
> > 
> Sorry for the delay and maybe I am missing something but it seems
> we can take care of such protocol or parsing/decoding differences
> even with device nodes since that seems independent of the
> interface used - per device debugfs attributes or per device
> device nodes.

You seem to be arguing that the two interfaces are equivalent, in which case
I say that we should follow ftrace's lead and use debugfs for this...

...but I still maintain that debugfs is also far easier to work with from
userspace.

> CoreSight trace solution is typically a SoC wide solution and
> hence can get used by non-Linux processors or hardware. Using
> debugfs would imply compiling it and exposing all the debug
> knobs even if the use case was to use the CoreSight solution for
> something that didn't need all that.

Many debug features require debugfs to be compiled, so I don't buy that as a
show-stopping argument in favour of using dev nodes. I also think that exposing
all of the debug knobs is actually a good thing, given the low-level nature of
coresight devices (where we're offloading most of the knowledge to userspace
anyway).

Will