from:"nwatkins"

[patch 0/1] extending low-level markers

2007-08-01 Thread nwatkins

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...)


#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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 1/1] Adds flavor field to __mark_marker

2007-08-01 Thread nwatkins

This patch demonstrates an extension field to the
low-level marker functionality, and updates macros to accept
this additional data.


Index: linux-2.6.22-rc6-mm1/include/linux/marker.h
===
--- linux-2.6.22-rc6-mm1.orig/include/linux/marker.h2007-08-01 
15:39:36.0 -0500
+++ linux-2.6.22-rc6-mm1/include/linux/marker.h 2007-08-01 15:39:37.0 
-0500
@@ -31,10 +31,14 @@
const char *args;   /* List of arguments litteraly transformed
 * into a string: "arg1, arg2, arg3".
 */
+   const int flavor;   /* site-defined marker flavor  */
immediate_char_t state; /* Immediate value state. */
marker_probe_func *call;/* Probe handler function pointer */
void *pdata;/* Private probe data */
-} __attribute__((aligned(8)));
+} __attribute__((aligned(32)));
+
+/* Default marker flavor */
+#define MARKER_DEFAULT 0
 
 #ifdef CONFIG_MARKERS
 
@@ -46,7 +50,7 @@
  * not add unwanted padding between the beginning of the section and the
  * structure. Force alignment to the same alignment as the section start.
  */
-#define __trace_mark(generic, name, format, args...)   \
+#define ___trace_mark(generic, flavor, name, format, args...)  \
do {\
static const char __mstrtab_name_##name[]   \
__attribute__((section("__markers_strings")))   \
@@ -60,7 +64,7 @@
static struct __mark_marker __mark_##name   \
__attribute__((section("__markers"))) = \
{ __mstrtab_name_##name, __mstrtab_format_##name,   \
-   __mstrtab_args_##name, { 0 },   \
+   __mstrtab_args_##name, flavor, { 0 },   \
__mark_empty_function, NULL };  \
asm volatile ( "" : : "i" (&__mark_##name));\
__mark_check_format(format, ## args);   \
@@ -81,6 +85,9 @@
}   \
} while (0)
 
+#define __trace_mark(generic, name, format, args...) \
+   ___trace_mark(generic, MARKER_DEFAULT, name, format, ## args)
+
 extern void module_marker_update(struct module *mod);
 #else /* !CONFIG_MARKERS */
 #define __trace_mark(generic, name, format, args...) \
Index: linux-2.6.22-rc6-mm1/include/asm-generic/vmlinux.lds.h
===
--- linux-2.6.22-rc6-mm1.orig/include/asm-generic/vmlinux.lds.h 2007-08-01 
15:39:36.0 -0500
+++ linux-2.6.22-rc6-mm1/include/asm-generic/vmlinux.lds.h  2007-08-01 
15:40:06.0 -0500
@@ -13,7 +13,7 @@
 #define DATA_DATA  \
*(.data)\
*(.data.init.refok) \
-   . = ALIGN(8);   \
+   . = ALIGN(32);  \
VMLINUX_SYMBOL(__start___markers) = .;  \
*(__markers)\
VMLINUX_SYMBOL(__stop___markers) = .;

-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 1/1] Adds flavor field to __mark_marker

2007-08-01 Thread nwatkins

This patch demonstrates an extension field to the
low-level marker functionality, and updates macros to accept
this additional data.


Index: linux-2.6.22-rc6-mm1/include/linux/marker.h
===
--- linux-2.6.22-rc6-mm1.orig/include/linux/marker.h2007-08-01 
15:39:36.0 -0500
+++ linux-2.6.22-rc6-mm1/include/linux/marker.h 2007-08-01 15:39:37.0 
-0500
@@ -31,10 +31,14 @@
const char *args;   /* List of arguments litteraly transformed
 * into a string: arg1, arg2, arg3.
 */
+   const int flavor;   /* site-defined marker flavor  */
immediate_char_t state; /* Immediate value state. */
marker_probe_func *call;/* Probe handler function pointer */
void *pdata;/* Private probe data */
-} __attribute__((aligned(8)));
+} __attribute__((aligned(32)));
+
+/* Default marker flavor */
+#define MARKER_DEFAULT 0
 
 #ifdef CONFIG_MARKERS
 
@@ -46,7 +50,7 @@
  * not add unwanted padding between the beginning of the section and the
  * structure. Force alignment to the same alignment as the section start.
  */
-#define __trace_mark(generic, name, format, args...)   \
+#define ___trace_mark(generic, flavor, name, format, args...)  \
do {\
static const char __mstrtab_name_##name[]   \
__attribute__((section(__markers_strings)))   \
@@ -60,7 +64,7 @@
static struct __mark_marker __mark_##name   \
__attribute__((section(__markers))) = \
{ __mstrtab_name_##name, __mstrtab_format_##name,   \
-   __mstrtab_args_##name, { 0 },   \
+   __mstrtab_args_##name, flavor, { 0 },   \
__mark_empty_function, NULL };  \
asm volatile (  : : i (__mark_##name));\
__mark_check_format(format, ## args);   \
@@ -81,6 +85,9 @@
}   \
} while (0)
 
+#define __trace_mark(generic, name, format, args...) \
+   ___trace_mark(generic, MARKER_DEFAULT, name, format, ## args)
+
 extern void module_marker_update(struct module *mod);
 #else /* !CONFIG_MARKERS */
 #define __trace_mark(generic, name, format, args...) \
Index: linux-2.6.22-rc6-mm1/include/asm-generic/vmlinux.lds.h
===
--- linux-2.6.22-rc6-mm1.orig/include/asm-generic/vmlinux.lds.h 2007-08-01 
15:39:36.0 -0500
+++ linux-2.6.22-rc6-mm1/include/asm-generic/vmlinux.lds.h  2007-08-01 
15:40:06.0 -0500
@@ -13,7 +13,7 @@
 #define DATA_DATA  \
*(.data)\
*(.data.init.refok) \
-   . = ALIGN(8);   \
+   . = ALIGN(32);  \
VMLINUX_SYMBOL(__start___markers) = .;  \
*(__markers)\
VMLINUX_SYMBOL(__stop___markers) = .;

-- 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 0/1] extending low-level markers

2007-08-01 Thread nwatkins

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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[patch 0/1] extending low-level markers

[patch 1/1] Adds flavor field to __mark_marker

[patch 1/1] Adds flavor field to __mark_marker

[patch 0/1] extending low-level markers

4 matches

Site Navigation

Mail list logo

Footer information