RE: [dsdp-tcf-dev] Need for a general "Properties" service?

["Spear, Aaron" <aaron_spear@xxxxxxxxxx>]

Hi Felix,

> I am not aware of any generalized properties service.  There 
> are several uses case for configuring complex things, like 
> trace triggering, trace filtering, hardware breakpoints and 
> watch points, etc.  I think that these different 
> configurations would be done through different TCF services 
> rather than one global service, no? 

Poor choice of wording on my part.  I was not thinking of a single
global service.

> Of course the way properties and constrains are represented
> could be shared.

This is what I meant.  The services themselves would be separate as it
makes sense.  As an implementation detail they could share a common
protocol.  Looking at the various TCF implementations on the target side
it is clear that it is quite easy to add an arbitrary service.  It is
also relatively easy to create a host side service proxy for it.  What
is less trivial is the creation of the full host side UI that utilizes
that service proxy.  Having something that could easily be used for
things like this would help encourage further adoption of TCF (and RSE).
I am thinking of the number of times I have cobbled together a little
telnet command interface over a socket or serial port so that I had the
ability to tweak properties of my system dynamically.  A general
property interface could be used for this.  Once people see how easy
this is, then taking the next step and creating an optimized user
interface would be more likely to happen.  (I do think you would want to
create a custom UI depending on the complexity of your trace control for
instance)

> It would be interesting to discuss/brainstorm this more 
> either as part of the MCA meetings or separately.

Trace and Profiling control and data are a related but decoupled topic
(from general properties).  I think there is great opportunity to create
some shared protocols here.  If you look at the data transmission that
is needed by products such as LTTng and various commercial "event
analyzers" that many of us sell, it basically comes down to a stream of
events that have all have:
-event id (what kind of event is it?)
-timestamp (of various flavors)
-context (board/core/process/thread)
-event specific data (a mutex lock event might have mutex id and current
recursion count or something)

Today Mentor has a proprietary binary protocol to transmit this kind of
data (that looks very similar to TCF :-). The data is binary and there
is an XML schema for interpreting it on the host. Now however we are
wanting to be able to correlate the events coming from our Nucleus OS
for example with those coming from LTTng.  It also seems that Nexus
trace events could also be presented in this same protocol, and adding
real-time trace into the mix brings in another level of interesting
possibilities (and corresponding complexity!) I am hoping we can create
an open protocol for this type of event data that has the following
sorts of attributes:
-must be efficient for transmission of gigabytes of data (i.e.
binary...)
-flexible notion of time stamping (wall clock, cpu cycle count,
"approximate" flag, etc)
-flexible notion of a context
-Arbitrary event specific data (integers, floats, strings, addresses
,etc)
-Possibly integrated compression scheme(s)
-priority of transmission is managed somehow (so sending the gigabytes
of data doesn't starve other services)

It seems we are not even to the knee of the exponential multi-core
revolution that is occurring.  Creating an open protocol that would
allow us to analyze multicore systems with very different technologies
sure seems like a wise move to me.  Of course we have to figure out if
all we will be doing is creating a vanilla standard that does many
things OK, but nothing well (I hope not).

Cheers,
Aaron

> 
> Thoughts?
> Felix
> 
> > -----Original Message-----
> > From: dsdp-tcf-dev-bounces@xxxxxxxxxxx [mailto:dsdp-tcf-dev- 
> > bounces@xxxxxxxxxxx] On Behalf Of Spear, Aaron
> > Sent: Friday, February 26, 2010 7:51 AM
> > To: DSDP TCF dev list
> > Subject: [dsdp-tcf-dev] Need for a general "Properties" service?
> > 
> > Hello all,
> > 
> > You may have discerned from my post a couple days ago that I have a 
> > current need to specify a protocol to use for controlling real-time 
> > trace collection.  In this particular use case I have to configure 
> > trace triggering (basically a collection of  addresses, 
> masks, counts, 
> > trigger
> > actions) and then events to collect.
> > 
> > It occurs to me that what I want is really pretty generic, and could
> be
> > described in terms of a hierarchy of properties where each property
> had
> > a name, description, "type" and value.  The type could be a finite
> list
> > of supported types such as -number (int,float, fixed point) -string 
> > -boolean -enumerated list of allowable values (strings)
> > 
> > We then have a shared RSE side GUI component that can for 
> instance use 
> > checkboxes for booleans, list box/combo boxes for the enum 
> list, edit 
> > box for the strings and integers.  Perhaps it also does 
> > validation/range checking and such as well.  Maybe 
> properties on the 
> > context that specifies how when changes are pushed so you 
> could send 
> > them as a
> group
> > after editing.
> > 
> > Looking at the existing registers service, it is nearly 
> exactly this 
> > already, but of course it makes the assumption that the values are 
> > purely numbers (and has sensible things like setm/getm for 
> multiple at 
> > one time and registers related context properties like "Readable", 
> > "Writable" etc)
> > 
> > Is this sort of general property service something that 
> already exists 
> > somewhere?  Is this something that others would find useful?  It
> occurs
> > to me that if it was really easy to bolt on to legacy code on the 
> > target side that it would be a very useful tool since there 
> would be 
> > no development necessary on the host at all.  It can then 
> be used as a 
> > simple interface to control just about anything.  The properties 
> > protocol could of course be used on the wire with shared 
> framework and 
> > completely custom UI on the host side too so that from a users 
> > perspective it was custom.  For example a bunch of custom graphical 
> > knob controls on top of integer properties.
> > 
> > Cheers,
> > Aaron
> > 
> > --
> > Aaron Spear      aaron_spear@xxxxxxxxxx
> > Debug Tools Architect/Staff Engineer
> > Embedded Systems Division
> > Mentor Graphics Corporation
> > Office: 303-679-8457
> > http://mentor.com/embedded
> > 
> > 
> > _______________________________________________
> > dsdp-tcf-dev mailing list
> > dsdp-tcf-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/dsdp-tcf-dev
> _______________________________________________
> dsdp-tcf-dev mailing list
> dsdp-tcf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-tcf-dev
>