Re: [linuxtools-dev] TMF: pluggable state provider contribution(s)

[Florian Wininger <florian.wininger@xxxxxxxxxx>]

Le 24/04/2013 16:59, Alexandre Montplaisir a écrit :
> Ah yes, sometimes we do "ongoing" queries to the state system to get
> attribute names.
> We can also do it for state values themselves (for example, in the
> kernel state provider, in sched_process_fork we will copy over the
> syscall_name attribute from the parent).
>
> I may be thinking ahead a bit, but I think we're slowly closing in on
> some syntax that could provide all the use cases.
> First I think the <stateChange> and <modify> could be merged together,
> since we will necessarily only have one target attribute and one target
> value, and we will not do more than one change to the same attribute
> (unless it's a separate state change for the same event, in which case
> it'd be a separate <stateChange> tag).
>
> So something like:
>
> <eventHandler eventName="name" [+ other possible filters]>
>   <stateChange type="modify">
>     # Path of the attribute
>     <attribute type="hardcoded" name="Threads" /> # type="hardcoded"
> could be the default
>     <attribute type="query">
>       # Query the ongoing state system at this timestamp
>       <attribute name="CPUs" />
>       <attribute type="field" fieldValue="cpu" />
>       <attribute name="Current_thread" />
>     </attribute>
>     <attribute name="Status" />
>
>     # Copy the Status from the parent process, for example
>     <value type="query">
>       <attribute name="Threads" />
>       <attribute type="query">
>         <attribute name="Threads" />
>         <attribute type="field" fieldValue="pid" />
>         <attribute name="PPID" />
>       </attribute>
>       <attribute name="Status" />
>     </value>
>   </stateChange>
> </eventHandler>
>
>
> Ok now my head is spinning, hehe. This is an example with funky nesting,
> most of the time it would be straight <attribute /> and <values />. But
> at least I think it can cover our known use cases. Any thoughts?
Very good ! I think that covers most use casesand it joined the formal
syntax I have proposed.
>
> I'm also thinking we could have some convenience "macros", like
> <property> in Ant, which could simplify accessing commonly-used
> locations. Like at the start of the file:
>
> <location id="CurrentThread">
>   <attribute name="CPUs" />
>   <attribute type="field" fieldValue="cpu" />
>   <attribute name="Current_thread" />
> </location>
>
> So then you can use:
> <stateChange type="modify">
>   <attribute type="location" id="CurrentThread" />
>   <value="blahblah" />
> </stateChange>
>
> But then it would require every event using it to have a field called
> "cpu". Not sure how to deal with that yet...
I was thinking about the same thing this morning. I had already thought
of that when I think about the formal syntax, otherwise it quickly
becomes unreadable.
In addition, this is how it is done in the KernelStateProvider to have
better performance and less queries with "relative path".

Cheers,
Florian