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

[Alexandre Montplaisir <alexmonthy@xxxxxxxxxxxx>]

On 13-04-23 09:41 PM, Florian Wininger wrote:
> Hi Alexandre and Aaron,
>
> Thank you for the discussion.
>
> Replies below,
>
> [...]
> I like this tree defition. But we must add the possibilities to make
> quey on the State Sytem in the path (as was proposed in /New Features in
> TMF about filters expressions/ subject)
> The XML is the conversion of your exemple :
> /Threads/[${/event/tid}]/Status = Running
> We want to be able to have
> /Threads/[${/CPUs/[${/event/Cpu}]/Current_thread}]/System_call = NULL   
> (it's the first instruction for a kernel exit_syscall event)
> and query the value of the node /CPUs/[${/event/Cpu}]/Current_thread in
> the state system, and use this value to make the <attribute
> fieldvalue="tid" />
>
> Exemple :
>
> <stateChange>
>     # Define the path to the attribute to be affected
>     <attribute name="Threads" /> # hard-coded value
>     <attribute query="StateSystem" > # begin the query of the SS query
> 	<attribute name="CPUs" />
> 	<attribute fieldvalue="Cpu" /> # a field in syscall event
> 	<attribute name="Cuurent_thread" />
>     </attribute>
>     <attribute name="System_call" />
>     # Apply the state change
>     <modify valueType="string" value="NULL" />
> </stateChange>
>
> equivalent : 
> /Threads/[${/CPUs/[${/event/Cpu}]/Current_thread}]/System_call = NULL
>

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?

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


Cheers,
Alexandre