Hey Florian,
I was thinking over lunch, why would we need assignation in the
specification of the filter?
So if we decide to make it java like, we can have
x.equals(y)
x.contains.(y)
x.compareTo(y)
x > y
x < y
x >= y
x <= y
!x.equals(y)
or C-like
x == y
...
...
x > y
x < y
x >= y
x <= y
x != y
(less work? ;) )
Also, I believe that ULaval has some very promising work in this
field, perhaps you could coordinate with Dr. Bechir Ktari, who's an
awesome and approachable fellow. Maybe you can avoid some overlap
like that.
The AFI git is actually mirrored at dorsal here:
http://git.dorsal.polymtl.ca/?p=afi.git
Then again, I may not get the full scope of the issue and be leading
you down a false path.
Hope this helps,
Matthew
On 13-03-12 10:23 AM, Florian Wininger
wrote:
Hi
all,
I'm looking to implement new
features in TMF about
filter expressions using the state system. I would appreciate
receiving your feedback on the proposal.
Currently, we can only specify constraints on the event context
and payload.
For example : event_type == sys_read && fd == 3
- Specify filter _expression_ using state information
The first feature is to add the use of state system attributes, to
be mixed with payload and context information. For example : /event/type
== "sys_read" && /system/${/event/pid}/files/${/event/fd}/pathname
== "/etc/passwd"
I want to propose a syntax to make this _expression_. The nodes in
the attribute tree are referenced using a hierarchical path. This
path is a sequence of names and can be expressed with the usual
notation, e.g. /processes/cpu/state. Each path component can be a
constant string, or a quoted string to escape special characters.
Alternatively a component can also be a number which is the put in
[]. This is used for directory nodes where all childs use integers
as names, which is more efficient than treating numbers as strings
and using strings. Finally, a component can be a variable where
the value of the component is obtained by referencing a path; the
$ notation is used as in shell scripts. We use the C/Java syntax,
'==' to compare and '=' to assign.
/processes/[4]/state == RUNNING
/processes/[4]/state_start_time ==
012032432
/processes/[4]/PPID == 1
/processes/[4]/user_mode/cumulative_time
== 5789357
/cpu/[0]/current_process == /processes/[1]
/processes/[${/processes/[4]/PPID}]/childs_cumulative_time
The model of the attribute tree is extended to make available as
well some dynamically computed information related to the current
context (channel, event). This additional information is not
assigned nor saved in the history tree. For example, some
information is associated with the current channel such as the
CPU. In addition, all the fields of the current event as well are
made available through the attribute tree syntax. For example, the
following information may be accessed through the associated
paths.
/event/timestamp
/event/type
/event/TID
/event/CPU
/event/field/next_process
/event/field/poll_array/[4]
These values can be used in logical and arithmetic expressions for
expressing conditions or assignments. Conditions are primarily
used in filters, for example in the detailed event list view. They
are also used as guards for state changes or as trigger for
creating abstract events.
- Specify expressions to determine state
entry / exit
The second feature is to provide _expression_ for state change.
Currently
this logic is coded in Java in files such as :
org.eclipse.linuxtools.lttng2.kernel.core/src/org/eclipse/linuxtools/internal/lttng2/kernel/core/stateprovider/CtfKernelStateInput.java
It
would be nice to be able to provide expressions for that.
This way, adding state for specific needs would not
require programming and we could import/export new types
of state systems easily (as part of the CTF metadata for
example).
Upon event of type sys_open:
/processes/${/event/pid}/files/${/event/fd}/pathname
= name
/processes/${/event/pid}/files/${/event/fd}/mode
= mode
Once we can easily refer to
state using such expressions, several additional features
become relatively easy to add such as new "virtual"
columns in the detailed event list computed based on an
_expression_ instead of being "event context" or "payload
information". In addition, such expressions could become
part of the CTF metadata to describe states, state entry
expressions, colors to associate with specific states in
the control flow view...
I would like to have the
developers' opinion on these two features. Do you see any major
problem or easy simplification for this syntax?
Thanks,
Florian
------------------------------------------------------------------------------------------------
Complete examples for transcription of the
CtfKernetStateInput.java :
case 1: // "exit_syscall":
/* Clear the current system call on the process */
/Threads/[${/CPUs/[${/event/Cpu}]/Current_thread}]/System_call =
NULL
/* Put the process' status back to user mode */
/Threads/[${/CPUs/[${/event/Cpu}]/Current_thread}]/Status =
PROCESS_STATUS_RUN_USERMODE
/* Put the CPU's status back to user mode */
/CPUs/[${/event/Cpu}]/Status = CPU_STATUS_RUN_USERMODE
case 8: // "sched_process_fork":
/* Assign the PPID to the new process */
/Threads/[${/event/child_tid}]/PPID = /event/parent_tid
/* Set the new process' exec_name */
/Threads/[${/event/child_tid}]/Exec_name = /event/child_comm
/* Set the new process' status */
/Threads/[${/event/child_tid}]/Status =
PROCESS_STATUS_WAIT_FOR_CPU
/* Set the process' syscall name, to be the same as the parent's
*/
/Threads/[${/event/child_tid}]/System_call =
/Threads/[${/event/parent_tid}]/System_call
case 11: // "lttng_statedump_process_state":
/* Set the process' name */
if( /Threads/[/event/tid]/Exec_name == Null)
/Threads/[/event/tid]/Exec_name = /event/name
/* Set the process' PPID */
if( /Threads/[/event/tid]/PPID == Null)
/Threads/[/event/tid]/PPID = /event/ppid
/* Set the process' status */
if( /Threads/[/event/tid]/Status == Null)
if(/event/status == 2)
/Threads/[/event/tid]/Status = PROCESS_STATUS_WAIT_FOR_CPU
else if(/event/status == 5)
/Threads/[/event/tid]/Status = PROCESS_STATUS_WAIT_BLOCKED
else
/Threads/[/event/tid]/Status = PROCESS_STATUS_UNKNOWN
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
|