Hey Florian,
Welcome to the cyberspace bulletin board of linux tools. Great to see
your feedback! So first, could you differentiate string from
identifiers? Is RUNNING a value or a variable? I'm asking because if
it's ambiguous.
Can we have "/jazz/blues/artist == ${/artist}" ?
Just out of curiosity, why not substring searches. Here's a real world
example.
You have a multi-threaded game you're tracing, let's call it "Doom"
Now it registers thread names as "Doom:PIDNum" or "Doom:audio"
"Doom:video" "Doom:AI" "Doom:physics[num]"
I think people would want- No- DEMAND! ;) that you have
/processes/*/name.contains("Doom")
^---- Wildcard
Also, the Java .equals may be less ambiguous than the C == for string
comparisons.
As for speed, the state system is made to be queried not so often, some
regex stuff may add more features while not killing performance as much
as you would think.
Food for thought. I am expecting to be proven wrong on this very soon.
Cheers,
Matthew
PS. please feel free to rebuke/ignore my arguments with vehemence, I am
just shooting out ideas to make sure when it's time to implement you're
sure it's what you want.
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@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
