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/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:16 EST