Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Trace Compass/Project Meetings/2016-03-04
- 1 Attendees
- 2 Minutes
- 2.1 Symbol provider contribution
- 2.2 tracecompass.org website comments
- 2.3 Schedule offline meeting to discuss Project View
- 2.4 IRQ model change patches
- 2.5 Integration state system / segment store
- 2.6 New "custom" state value types
- 2.7 Demo of the IRQ analysis
- 2.8 Feedback on the medium used for the meeting
- 3 Action items
- Alexandre Montplaisir (EfficiOS)
- Jonathan Rajotte (EfficiOS)
- Matthew Khouzam (Ericsson)
- Patrick Tassé (Ericsson)
- Marc-André Laperle (Ericsson)
- Jean-Christian Kouamé (Ericsson)
- Geneviève Bastien (Polytechnique)
- Francis Giraldeau (Polytechnique)
Symbol provider contribution
- Alex has done some review so far, a second committer should also look at it.
- Matthew offered to take a look a it
- CQ will be needed
- We're past the normal deadline for CQs for Neon, hopefully we can still get it in.
- Another CQ will be required for the LTTng 2.8 XSD anyway (should be available around 2.8 RC1, coming in the next days/weeks)
tracecompass.org website comments
- There was a comment that the User Guides don't look very good, the CSS is rather plain
- This is actually controlled by the .help plugins in the git tree, not directly controllable from the website. But could be improved in the git tree.
Schedule offline meeting to discuss Project View
- With the introduction of LTTng-Analyses integration and "static" analyses, we need a new way to present these to the user.
- These "static" analyses produce reports, which won't change their contents, unlike dynamic views that respond to signals.
- Ultimately, what is the difference between a "pinned" dynamic view and a report?
- An offline meeting will be scheduled, probably next week, to discuss this in more details.
IRQ model change patches
- The patch to modelize IRQs by CPU instead of a single resource were merged:
There are still more fixes needed:
- SoftIRQs can be "interrupted" by hardware IRQs
- CPU states don't handle all cases correctly. They should eventually be moved to being "aggregate" states of the thread / soft IRQ / IRQ beneath them.
Matthew will be working on those next.
Integration state system / segment store
- Geneviève mentioned upcoming work that will need integrating segment store and statesystem components together
- The main problems seemed to be that:
- The segment store doesn't have a backend on disk
- The time graph views are currently populated using a state system
- It was pointed out that fixing these problems might be the best long-term strategy, rather than "cramming" SS components in the segment store and vice versa.
- A backend talking to a database using JDBC was prototype initially, could be a good avenue.
- EclipseLink was mentioned, which is a higher-level API above JPA/JDBC, which may make this even easier.
- A new type of time graph view, that gets its data directly from a segment store, could be implemented.
New "custom" state value types
- Related to the previous point, analyses may want to specify their own type of state values, which will provide their own serialization/deserialization methods.
- Because the Type enum is used in many places, it wouldn't be trivial to switch all current state values to a generic model. For now a CustomStateValue type is probably the best approach.
- Introduction of a "factory manager", and external plugins could register their factory that creates state values of their provided types.
- The "id" for each type would be a "byte", because it is serialized and written every time.
- High possibility of clashes once several external plugins start providing their own SV types
- Eventually a string ID with the package name, like is used for view IDs and extension points, could be used, and mapped to an integer which is written. Just need to persist this id-integer mapping.
- As the overall approach seemed good, Geneviève will continue in this direction.
Demo of the IRQ analysis
- Matthew demo'ed a concept of a new IRQ analysis, which shows handlers instead of straight IRQ numbers
- Will be presented to devs of LTTng and lttng-analyses
Feedback on the medium used for the meeting
- appear.in worked okay overall, although some users reported cuts or jittering audio at times
- Didn't seem to work well in low-bandwith situations (Francis could join but was extremely laggy, even in audio-only).
- The limit of 8 participants was actually reached a couple times, which means some people may have been locked out from entering.
- Other solutions could be investigated, the main problem being the limit of 8 participants which was already reached.
- Matthew: second review of https://git.eclipse.org/r/#/c/67442/
- Alex & others: Schedule meeting next week to discuss new analyses and Project View
- Marc-André: Open a bug against Hudson/HIPP because half of Gerrit patches are failing (hardware problems?)
- All: Investigate other tools to hold the online meetings