Messages in this thread | | | Date | Wed, 1 Aug 2007 16:57:24 -0500 | From | nwatkins@ittc ... | Subject | [patch 0/1] extending low-level markers |
| |
Mathieu
I have been working with your Kernel Markers infrastructure now for some time and have run into an extendability issue.
Essentially I am failing to find a way to extend the current __trace_mark macro with site-specific context. That is, I would like the ability to create different 'types' of instrumentation points by bulding upon the __trace_mark macro. A consumer of this marker could examine the type of marker, and attach an appropriate callback function / private data.
I have included a patch which adds a flavor field to the __trace_mark macro. This simplified example demonstrates the functionality I'm looking for:
#define __trace_mark(flavor, name, format, args...) <current macro plus the flavor field>
#define marker_flavor_XXX(name, format, args...) __trace_mark(XXX, name, format, args)
Here a marker of type XXX is build upon the __trace_mark macro. When a consumer of type XXX finds markers with the XXX flavor appropriate registration can take place.
Unless I don't fully understand all the use cases of the markers, I don't see any other way to do this except to encode the 'type' information in the name of the marker, and require the consumer to parse the string to determine the type. Restricting the names of the markers in this way seems like a bad solution.
Any help and feedback is greatly appreciated.
- Noah
-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |