Messages in this thread |  | | From | Karim Yaghmour <> | Subject | Re: DProbes with LTT | Date | Tue, 10 Oct 2000 18:55:11 -0400 |
| |
Richard,
Definitely a good idea. Enabling the programmer to specify the format of the custom data to be printed would be great. Having this in mind, this is why LTT has two events to enable custom tracing, the "New event" and the "custom event". Therefore, extending the definition of "New event" leaves a lot of possibilities open.
Here's what I had in mind for LTT (feel free to comment on this as it is only a design for now): In the creation of a new event, the caller of the "create event ID" function would provide the following information: 1) An event-type string that will mainly be used to identify this amongst the other events. ex: an IRQ entry has a string describing it which is "IRQ entry", it also has a string describing the event in detail, this is the purpose of #2 below. 2) A printf-style string used to print out the formatted event string. ex: "XYZ Driver received unknown event %d on I/O port %03X with error %C" 3) A 0-terminated table containing a structure-type which has 2 entries: -A data-length type (fixed or variable) -A data-length (if fixed) Each entry would describe each of the data types that will be used with the printf-like string ex using the above string: the "%d" would be the first entry with a fixed data-length of 4 bytes, the "%03X" would be the second entry with a fixed data-length of 4 bytes, the "%C" would be the third entry with a fixed data-length of 2 bytes. In the case of a "%s", the data-length type would be "variable". The last entry in the table would be filled with zeros as to show the table's end.
As previously mentioned, the "create event ID" would return a unique event Id for the newly created event.
With this scheme, recording a custom event would amount to providing the existing trace function with the custom event ID and a pointer to a buffer containing the packed data to be used with the pre-provided string. Using the example above, the caller would pass a buffer containing the following data packed in a single buffer: 4 bytes data for "%d", 4 bytes data for "%03X", 2 bytes for "%C", for a total of a 10 byte-buffer. The tracing function will automatically determine the length of the buffer since it was determined upon event ID creation. In the case that the buffer contained a string, the first word before the string would contain the string size so that the function would determine the exact length of the whole buffer. That said, it must be stressed that using strings in trace statements is expensive given the processing cost of finding out buffer lengths and so on. Therefore, strings should be regarded as a last resort.
Once the trace is complete, the trace visualization tool would retrieve the custom events list and read the trace according to those descriptions. It would then output the description strings and the details string to signal the event's occurrence in the trace. To print out the details string, printf or one of it's variants would be provided with the printf-like string, provided upon event-type creation, and the data belonging to the event traced. With the example above, this would be something like: printf("XYZ Driver received unknown event %d on I/O port %03X with error %C", "the 4 bytes given for %d", "the 4 bytes given for %03X" , etc.);
This is figurative as the real parameters would most likely be pointers and since the printf call would have a variable amount of parameters (as always).
The advantage of using this rather than major-minor code is that the data formatting capabilities provided are exactly the ones most programmers are already familiar with. Though I might have missed some limitations of this scheme that the major-minor code scheme overcomes.
What do you think?
Karim
richardj_moore@uk.ibm.com wrote: > > Karim, > > I've been back through an initial evaluation we did for LTT, back in May. > One of the feature we highlighted we'd like to see was an ability to > specify custom formatting templates. Our original OS/2 trace facility > allowed the user to generate formatting templates which would specify > printf-like controls. The templates were defined per major-minor code > specification, which was used to identify uniquly a formatting type and was > recorded with the trace record in the header. > > We'd like to see that functionality in LTT. Would port the code from OS/2 > if LTT had a suitable formatting exit for custom events. Any thoughts on > this? > > Richard > > Richard Moore - RAS Project Lead - Linux Technology Centre (PISC). > > http://oss.software.ibm.com/developerworks/opensource/linux > Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183 > IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK
-- =================================================== Karim Yaghmour karym@opersys.com Operating System Consultant (Linux kernel, real-time and distributed systems) =================================================== - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |