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

[Michel Dagenais <michel.dagenais@xxxxxxxxxx>]

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

We dont yet support all these things in LTTng but obviously they are of interest for the future. We had filters though. Interestingly, these types of parameters and more are being implemented in the GDB tracepoints. GDB tracepoints are able to interface to LTTng User Space Tracing tracepoints.

Eventually, I would like to have several possible sources of tracing data:

- LTTng/Ftrace kernel tracepoints (TRACE_EVENT)
- LTTng User Space Tracing tracepoints
- GDB "dynamic" tracepoints (handled in the traced process without ptrace roundtrip)
- kernel "dynamic" tracepoints through kprobes

Then, when a tracepoint is encountered, you could have a trivial or a more complex probe handler connected in order to:

- write the event and statically provided arguments to the trace. Dynamic tracepoints have no static argument.

- extract additional values to write to the trace. The debugging information can be used to know where these values are and a very simple bytecode expression is sent to tell how to fetch the value (address, indirection, offset...). GDB tracepoints have this and Ftrace as well to a certain point.

- test some of the values (count, time, argument, local variable), static or extracted, and assign state variables (e.g. count) or decide to write the event or not (filter).

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

The needs for the tracing protocol are indeed fairly generic (list, set triggers, filters...) and we should be able to share it among possibly several tracing systems. 

Using generic commands for the tracing control protocol is obviously feasible. This is how you control kernel tracing with either LTTng or Ftrace in Linux. We should then be able to use that through RSE up to a certain point. It will not be as efficient since you need possibly more commands or parsing to get the same result. Error handling and reporting may not be as precise as well. As long as the trace data is handled properly as a binary blob, the lower performance for the rest does not matter as much.

RSE will not be usable directly to handle user space tracing as these are controled through commands to a socket instead of a pseudo-filesystem.

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

The GNOME configuration system works in this way. You have a tree of properties and a generic properties editor may be used to change any setting in the configuration database. However, they also provide more user-friendly special purpose configuration editors for all the common settings.

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

Of course, SNMP also works in a similar way. You set the property time-to-reboot to 0 when you want to reboot your router. Humm, a few thoughts on this:

- it may not be a good idea to start by building a grandiose and very generic framework, it is often better to build a lean framework once we already have a few specific systems that can nicely be merged.

- a small properties based protocol within TCF and hooks for plugins to handle part of the properties tree could be interesting. It may get used by small specific applications with simple needs and not needing their own specialized protocol. It is not clear to me if tracing would fit there.