Hi all. I work for a company called MontaVista and we’re using TimeDoctor to implement trace views for our linux kernel. I’ve come to a couple of limitations that I would like to make adjustments for. Namely, the lack of ability to add or remove event types/canvases and definitions at run time. I will usually do this before reading our file data in which is converted to TDI. The only way I found to extend these types is to modify a switch statement.
My proposal is to add extension points into TimeDoctor to allow for outside configuration. There would be two extension points. One would be to define an event set. For example: the current list of supported events in TD is an event set. The second extension would define the event and which set it belongs to. This would allow us to swap sets so that we can make more intelligent decisions about how the data is displayed.
Anyone else run into these types of problems? I would like to make these changes and get them back into time doctor. How would I go about checking this into TimeDoctor?
I'm not sure to fully understand your need. There are multiple levels of customization that we can think of.
The graphical representation of a given line (ie a canvas) is selected according to the line type (task, event, agent, ...) as defined by the NAM command.
Are you saying that you'd like to have some new graphical representations for some (new) line types. If it is the case an extension point can be introduced to provide a new line type (a unique identifier) and a canvas (implementing an interface compatible with TraceCanvas). With such a mechanism you'll be able to have some custom lines. However this won't be "at runtime" but at startup-time (if TM finds a line type that is not know it will try to load a plug-in that would provide the definition for this type). How is this compatible with your request to be able to "add or remove event types/canvases and definitions at run time" ?
You then propose to introduce 2 extension points to introduce new events/event sets. If I understand this requirement you want to be able to dynamically (ie. at runtime) change the mapping between a line type and its graphical representation. Is is correct ? If it is then one can imagine to introduce an extension point to add some new canvas types, and then extend the GUI (propably a preference page) to allow the user to select the mapping (ie which canvas has to be used to display a given line type). In that case no new line type has to be introduce, only the mapping would change. Note however that this mapping will hold for all lines of a given line type (ie if you consider the 'events' line type, all events will be displayed the same way).
Did you already modify time doctor to support some new canvas/types ? If it is the case can you attach the modifications you made in order to help us understanding your use-case.
>> I'm not sure to fully understand your need.
Thanks for the response. I abused the word "run-time" here so I apologize for that confusion. My meaning of run-time is that the code is static. Very much not run-time. Extension points are loaded at run-time albiet from static .xml files. But that makes the code data driven and hence run-time. Yes, I would like to change TD's behavior not at run-time but when TD discovers extension points from other plugins.
>> If it is the case an extension point can be introduced
> to provide a new line type....
Yes, this is what I am after. I think one extension point is insufficient in the long run, but I'll cover that next.
>> If I understand this requirement you want to be able to
> dynamically (ie. at runtime) change the mapping between a
> line type and its graphical representation.
No. I will refrain from the use of the word “run-time” to avoid further confusion :-). The idea of the extension points is to modify the GUI and the interpretation of the LINES in the format files by their NAM commands. The idea of having a ‘set’ logically follows adding an extension point for new events. This means that a set would be required when loading a file or stream. Sets protect multiple plugins that use TD from stepping on each others toes when extending TD dynamics.
>> preference page
I didn't see a preference page, but I can already think of all sorts of things to add to one. I'll cross that bridge when we come to it though :-).
Hopefully I’m making more sense today. I'm not confused about how to get what I want done, I'm concerned that the work won't be accepted into time doctor for one reason or another. If this turns out to be the case it'll be a waste of time for us as we are looking to add to the community and in turn take bug fixes from updates of TD. I hope we can work out solutions.
Would you need changes to the parser and model too, or only change the GUI rendering for 'existing' types?
Not sure I see a requirement for having an extension point for just the GUI part. Do you expect many different 'GUI's will be needed for rendering the pre-defined types? In that case it sounds a bit like abusing specific events (that already have a GUI representation tailored for the type of event) for different purposes. It would be better to introduce a new type of event, too.
I agree, adding an extension points for just the Canvas wouldn’t be very useful. My understanding of TimeDoctor has grown now that I’ve been playing with the code. I see now that the canvas is one part in that. Rather than a canvas, I defined an Event Definition to cover the various features of events. I have integrated my idea for extension points and with some code cleanup and a few appropriate comments I believe it to be ready for digestion. I’ll submit this in a bug or enhancement request as I mentioned in another post.
I found that there was a lot of opportunity to decouple the Event Defintions (LineTypes/Canvases/filling steps) from the model and the parser. I found this easier overall with the model, but the parser still has some specific references to certain event types. I would love to manage these dependencies though extensions as well but that’s its own chunk of work and will require some thought. I also think it would be more effective to have the Event Definitions manage some of their own parsing while utilizing a common structure to do so.
The extension point as I have written allows one to specify:
-Id as a string: Id uses the Integers 0-11 to map directly to the parsing mechanism that was previously there.
-Name as a string: Name is displayed in the heading for that type of event.
-lineClass as a java resource: Must extend SampleLine. I decoupled some event specific references scattered about the other plugins and consolidated the work into the SampleClass. Extended interfaces reimplment these methods to provide the same functionality as was there previously.
-ColorMain: Equivalant to color index 0
-ColorSecondary: Equivalant to color index 1
These seem to be all the extension point needs for now. The Canvas is actually initialized through SampleLine but in such a way that the code can be split between a core plugin and a UI plugin if desired.
I’ve also been working on an extension point for an input source to allow for our plugins to provide their own feed into TimeDoctor without having to write to a file and opening it through eclipse. This will start simple but I can see this growing into a useful mechanism for providing live data via the network or a hard disk or etc.
Sounds good, looking forward to your patch to fully understand.
The parser indeed has a few specifics for detecting and dealing with task pre-emption and nested ISRs. Since it is not that big of a component, having multiple parsers iso. extension points for new line/canvas types could work, too.
Did you decide on having a LTTng parser (replacing original parser) or converter (translating into TDI format) yet?
I'm really close to having everything ready, I hope to have this submitted for you perusal by end of my business day. We decided to do the LTTng parser, but we haven't worked out the details of how we would like to work it into timedoctor. At first I thought we would output a temporary file format and pass that into TimeDoctor. Now it's looking like we want the parsing to be on the fly and converted to TimeDoctor string line format to be further parsed by TimeDoctor. LTTng files can get very large. Once we get the mechanism described above working, we want to optimize space and memory usage.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.