[patch 0/7] Linux Kernel Markers (redux)

[patch 0/7] Linux Kernel Markers (redux)

[Mathieu Desnoyers]

Hi Andrew,

Following Christoph Hellwig's suggestion, aiming at a Linux Kernel Markers
inclusion for 2.6.24, I made a simplified version of the Linux Kernel Markers.
There are no more dependencies on any other patchset.

The modification only involved turning the immediate values into static
variables and adapting the documentation accordingly. It will have a little more
data cache impact when disabled than the version based on the immediate values,
but it is far less complex.

Since things have not moved much in the markers area recently (most of the
concerns were about the immediate values), I expect it to be ready for 2.6.24.

It applies to 2.6.23-rc7-mm1

Patches apply in this order:

seq_file_sorted.patch
module.c-sort-module-list.patch
kconfig-instrumentation.patch
linux-kernel-markers-architecture-independent-code.patch
linux-kernel-markers-instrumentation-menu.patch
linux-kernel-markers-documentation.patch
linux-kernel-markers-port-blktrace-to-markers.patch

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

[patch 1/7] Seq_file add support for sorted list

[Mathieu Desnoyers]

[-- Attachment #1: seq_file_sorted.patch --]
[-- Type: text/plain, Size: 3709 bytes --]

Add support for sorted list in seq_file. It aims at changing the way
/proc/modules and kallsyms iterates on the module list to remove a race between
module unload and module/symbol listing.

The list is sorted by ascending list_head pointer address.

Changelog:

When reading the data by small chunks (i.e. byte by byte), the index (ppos) is
incremented by seq_read() directly and no "next" callback is called when going
to the next module.

Therefore, use ppos instead of m->private to deal with the fact that this index
is incremented directly to pass to the next module in seq_read() after the
buffer has been emptied.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
---
 fs/seq_file.c            |   47 +++++++++++++++++++++++++++++++++++++++++++++++
 include/linux/seq_file.h |   20 ++++++++++++++++++++
 2 files changed, 67 insertions(+)

Index: linux-2.6-lttng/fs/seq_file.c
===================================================================
--- linux-2.6-lttng.orig/fs/seq_file.c	2007-08-25 14:39:03.000000000 -0400
+++ linux-2.6-lttng/fs/seq_file.c	2007-08-27 11:11:33.000000000 -0400
@@ -510,3 +510,50 @@ struct list_head *seq_list_next(void *v,
 }
 
 EXPORT_SYMBOL(seq_list_next);
+
+struct list_head *seq_sorted_list_start(struct list_head *head, loff_t *ppos)
+{
+	struct list_head *lh;
+
+	list_for_each(lh, head)
+		if ((unsigned long)lh >= *ppos) {
+			*ppos = (unsigned long)lh;
+			return lh;
+		}
+	return NULL;
+}
+
+EXPORT_SYMBOL(seq_sorted_list_start);
+
+struct list_head *seq_sorted_list_start_head(struct list_head *head,
+		loff_t *ppos)
+{
+	struct list_head *lh;
+
+	if (!*ppos) {
+		*ppos = (unsigned long)head;
+		return head;
+	}
+	list_for_each(lh, head)
+		if ((unsigned long)lh >= *ppos) {
+			*ppos = (long)lh->prev;
+			return lh->prev;
+		}
+	return NULL;
+}
+
+EXPORT_SYMBOL(seq_sorted_list_start_head);
+
+struct list_head *seq_sorted_list_next(void *p, struct list_head *head,
+		loff_t *ppos)
+{
+	struct list_head *lh;
+	void *next;
+
+	lh = ((struct list_head *)p)->next;
+	next = (lh == head) ? NULL : lh;
+	*ppos = next ? (unsigned long)next : -1UL;
+	return next;
+}
+
+EXPORT_SYMBOL(seq_sorted_list_next);
Index: linux-2.6-lttng/include/linux/seq_file.h
===================================================================
--- linux-2.6-lttng.orig/include/linux/seq_file.h	2007-08-25 14:39:03.000000000 -0400
+++ linux-2.6-lttng/include/linux/seq_file.h	2007-08-27 11:11:33.000000000 -0400
@@ -63,5 +63,25 @@ extern struct list_head *seq_list_start_
 extern struct list_head *seq_list_next(void *v, struct list_head *head,
 		loff_t *ppos);
 
+/*
+ * Helpers for iteration over a list sorted by ascending head pointer address.
+ * To be used in contexts where preemption cannot be disabled to insure to
+ * continue iteration on a modified list starting at the same location where it
+ * stopped, or at a following location. It insures that the lost information
+ * will only be in elements added/removed from the list between iterations.
+ * void *pos is only used to get the next list element and may not be a valid
+ * list_head anymore when given to seq_sorted_list_start() or
+ * seq_sorted_list_start_head().
+ */
+extern struct list_head *seq_sorted_list_start(struct list_head *head,
+		loff_t *ppos);
+extern struct list_head *seq_sorted_list_start_head(struct list_head *head,
+		loff_t *ppos);
+/*
+ * next must be called with an existing p node
+ */
+extern struct list_head *seq_sorted_list_next(void *p, struct list_head *head,
+		loff_t *ppos);
+
 #endif
 #endif

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

[patch 2/7] Sort module list by pointer address to get coherent sleepable seq_file iterators

[Mathieu Desnoyers]

[-- Attachment #1: module.c-sort-module-list.patch --]
[-- Type: text/plain, Size: 5601 bytes --]

A race that appears both in /proc/modules and in kallsyms: if, between the
seq file reads, the process is put to sleep and at this moment a module is
or removed from the module list, the listing will skip an amount of
modules/symbols corresponding to the amount of elements present in the unloaded
module, but at the current position in the list if the iteration is located
after the removed module.

The cleanest way I found to deal with this problem is to sort the module list.
We can then keep the old struct module * as the old iterator, knowing the it may
be removed between the seq file reads, but we only use it as "get next". If it
is not present in the module list, the next pointer will be used.

By doing this, removing a given module will now only fuzz the output related to
this specific module, not any random module anymore. Since modprobe uses
/proc/modules, it might be important to make sure multiple concurrent running
modprobes won't interfere with each other.


Small test program for this:

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

#define BUFSIZE 1024

int main()
{
	int fd = open("/proc/modules", O_RDONLY);
	char buf[BUFSIZE];
	ssize_t size;

	do {
		size = read(fd, buf, 1);
		printf("%c", buf[0]);
		usleep(100000);
	} while(size > 0);

	close(fd);
	return 0;
}


Actual test (kernel 2.6.23-rc3):

dijkstra:~# lsmod
Module                  Size  Used by
pl2303                 18564  0
usbserial              29032  1 pl2303
ppdev                   7844  0
sky2                   37476  0
skge                   36368  0
rtc                    10104  0
snd_hda_intel         265628  0

  (here, while we are printing the 2nd line, I rmmod pl2303)
compudj@dijkstra:~/test$ ./module
pl2303 18564 0 - Live 0xf886e000
usbserial 29032 1 pl2303, Live 0xf8865000
sky2 37476 0 - Live 0xf884f000
skge 36368 0 - Live 0xf8838000
rtc 10104 0 - Live 0xf8825000

We see the the 2nd line is garbage.

Now, with my patch applied:
  (here, while we are printing the rtc module, I rmmod rtc)
nd_hda_intel 268708 0 - Live 0xf8820000
ltt_control 2372 0 - Live 0xf8866000
rtc 10392 0 - Live 0xf886d000
skge 36768 0 - Live 0xf8871000
ltt_statedump 8516 0 - Live 0xf887b000

We see that since the rtc line was already in the buffer, it has been
printed completely.


  (here, while we are printing the skge module, I rmmod rtc)
snd_hda_intel 268708 0 - Live 0xf8820000
ltt_control 2372 0 - Live 0xf8866000
rtc 10392 0 - Live 0xf886d000
skge 36768 0 - Live 0xf8871000
ltt_statedump 8516 0 - Live 0xf887b000
sky2 38420 0 - Live 0xf88cd000

We see that the iteration continued at the same position even though the
rtc module, located in earlier addresses, was removed.

Changelog:

When reading the data by small chunks (i.e. byte by byte), the index (ppos) is
incremented by seq_read() directly and no "next" callback is called when going
to the next module.

Therefore, use ppos instead of m->private to deal with the fact that this index
is incremented directly to pass to the next module in seq_read() after the
buffer has been emptied.

Before fix, it prints the first module indefinitely. The patch fixes
this.

Changelog:
- Remove module_mutex usage: depend on functions implemented in module.c for
  that.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
---
 kernel/module.c |   23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

Index: linux-2.6-lttng/kernel/module.c
===================================================================
--- linux-2.6-lttng.orig/kernel/module.c	2007-09-21 14:19:51.000000000 -0400
+++ linux-2.6-lttng/kernel/module.c	2007-09-21 14:20:43.000000000 -0400
@@ -63,7 +63,8 @@ extern int module_sysfs_initialized;
 #define INIT_OFFSET_MASK (1UL << (BITS_PER_LONG-1))
 
 /* List of modules, protected by module_mutex or preempt_disable
- * (add/delete uses stop_machine). */
+ * (add/delete uses stop_machine). Sorted by ascending list node address.
+ */
 static DEFINE_MUTEX(module_mutex);
 static LIST_HEAD(modules);
 static DECLARE_MUTEX(notify_mutex);
@@ -2116,10 +2117,24 @@ nomodsectinfo:
 /*
  * link the module with the whole machine is stopped with interrupts off
  * - this defends against kallsyms not taking locks
+ * We sort the modules by struct module pointer address to permit correct
+ * iteration over modules of, at least, kallsyms for preemptible operations,
+ * such as read(). Sorting by struct module pointer address is equivalent to
+ * sort by list node address.
  */
 static int __link_module(void *_mod)
 {
-	struct module *mod = _mod;
+	struct module *mod = _mod, *iter;
+
+	list_for_each_entry_reverse(iter, &modules, list) {
+		BUG_ON(iter == mod);	/* Should never be in the list twice */
+		if (iter < mod) {
+			/* We belong to the location right after iter. */
+			list_add(&mod->list, &iter->list);
+			return 0;
+		}
+	}
+	/* We should be added at the head of the list */
 	list_add(&mod->list, &modules);
 	return 0;
 }
@@ -2384,12 +2399,12 @@ unsigned long module_kallsyms_lookup_nam
 static void *m_start(struct seq_file *m, loff_t *pos)
 {
 	mutex_lock(&module_mutex);
-	return seq_list_start(&modules, *pos);
+	return seq_sorted_list_start(&modules, pos);
 }
 
 static void *m_next(struct seq_file *m, void *p, loff_t *pos)
 {
-	return seq_list_next(p, &modules, pos);
+	return seq_sorted_list_next(p, &modules, pos);
 }
 
 static void m_stop(struct seq_file *m, void *p)

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

[patch 3/7] Combine instrumentation menus in kernel/Kconfig.instrumentation

[Mathieu Desnoyers]

[-- Attachment #1: kconfig-instrumentation.patch --]
[-- Type: text/plain, Size: 30463 bytes --]

Quoting Randy:

"It seems sad that this patch sources Kconfig.marker, a 7-line file,
20-something times.  Yes, you (we) don't want to put those 7 lines
into 20-something different files, so sourcing is the right thing.

However, what you did for avr32 seems more on the right track to me:
make _one_ Instrumentation support menu that includes PROFILING,
OPROFILE, KPROBES, and MARKERS and then use (source) that in all
of the arches."

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
---
 arch/alpha/Kconfig             |    2 -
 arch/alpha/oprofile/Kconfig    |   23 ----------------------
 arch/arm/Kconfig               |    2 -
 arch/arm/oprofile/Kconfig      |   42 -----------------------------------------
 arch/blackfin/Kconfig          |    2 -
 arch/blackfin/oprofile/Kconfig |   29 ----------------------------
 arch/cris/Kconfig              |    2 +
 arch/frv/Kconfig               |    2 +
 arch/h8300/Kconfig             |    2 +
 arch/i386/Kconfig              |   25 ------------------------
 arch/i386/oprofile/Kconfig     |   17 ----------------
 arch/ia64/Kconfig              |   15 --------------
 arch/ia64/oprofile/Kconfig     |   20 -------------------
 arch/m32r/Kconfig              |    2 -
 arch/m32r/oprofile/Kconfig     |   23 ----------------------
 arch/m68k/Kconfig              |    2 +
 arch/m68knommu/Kconfig         |    2 +
 arch/mips/Kconfig              |    2 -
 arch/mips/oprofile/Kconfig     |   23 ----------------------
 arch/parisc/Kconfig            |    2 -
 arch/parisc/oprofile/Kconfig   |   23 ----------------------
 arch/powerpc/Kconfig           |   15 --------------
 arch/powerpc/oprofile/Kconfig  |   24 -----------------------
 arch/ppc/Kconfig               |    2 -
 arch/s390/Kconfig              |   16 ---------------
 arch/s390/oprofile/Kconfig     |   22 ---------------------
 arch/sh/Kconfig                |    2 -
 arch/sh/oprofile/Kconfig       |   23 ----------------------
 arch/sh64/Kconfig              |    2 -
 arch/sh64/oprofile/Kconfig     |   23 ----------------------
 arch/sparc/Kconfig             |    6 -----
 arch/sparc/oprofile/Kconfig    |   17 ----------------
 arch/sparc64/Kconfig           |   15 --------------
 arch/sparc64/oprofile/Kconfig  |   17 ----------------
 arch/um/Kconfig                |    2 +
 arch/v850/Kconfig              |    2 +
 arch/x86_64/Kconfig            |   15 --------------
 arch/x86_64/oprofile/Kconfig   |   17 ----------------
 arch/xtensa/Kconfig            |    2 +
 kernel/Kconfig.instrumentation |   40 +++++++++++++++++++++++++++++++++++++++
 40 files changed, 72 insertions(+), 452 deletions(-)

Index: linux-2.6-lttng/arch/alpha/oprofile/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/alpha/oprofile/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,23 +0,0 @@
-
-menu "Profiling support"
-	depends on EXPERIMENTAL
-
-config PROFILING
-	bool "Profiling support (EXPERIMENTAL)"
-	help
-	  Say Y here to enable the extended profiling support mechanisms used
-	  by profilers such as OProfile.
-	  
-
-config OPROFILE
-	tristate "OProfile system profiling (EXPERIMENTAL)"
-	depends on PROFILING
-	help
-	  OProfile is a profiling system capable of profiling the
-	  whole system, include the kernel, kernel modules, libraries,
-	  and applications.
-
-	  If unsure, say N.
-
-endmenu
-
Index: linux-2.6-lttng/arch/arm/oprofile/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/arm/oprofile/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,42 +0,0 @@
-
-menu "Profiling support"
-	depends on EXPERIMENTAL
-
-config PROFILING
-	bool "Profiling support (EXPERIMENTAL)"
-	help
-	  Say Y here to enable the extended profiling support mechanisms used
-	  by profilers such as OProfile.
-
-
-config OPROFILE
-	tristate "OProfile system profiling (EXPERIMENTAL)"
-	depends on PROFILING
-	help
-	  OProfile is a profiling system capable of profiling the
-	  whole system, include the kernel, kernel modules, libraries,
-	  and applications.
-
-	  If unsure, say N.
-
-if OPROFILE
-
-config OPROFILE_ARMV6
-	bool
-	depends on CPU_V6 && !SMP
-	default y
-	select OPROFILE_ARM11_CORE
-
-config OPROFILE_MPCORE
-	bool
-	depends on CPU_V6 && SMP
-	default y
-	select OPROFILE_ARM11_CORE
-
-config OPROFILE_ARM11_CORE
-	bool
-
-endif
-
-endmenu
-
Index: linux-2.6-lttng/arch/blackfin/oprofile/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/blackfin/oprofile/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,29 +0,0 @@
-menu "Profiling support"
-depends on EXPERIMENTAL
-
-config PROFILING
-	bool "Profiling support (EXPERIMENTAL)"
-	help
-	  Say Y here to enable the extended profiling support mechanisms used
-	  by profilers such as OProfile.
-
-config OPROFILE
-	tristate "OProfile system profiling (EXPERIMENTAL)"
-	depends on PROFILING
-	help
-	  OProfile is a profiling system capable of profiling the
-	  whole system, include the kernel, kernel modules, libraries,
-	  and applications.
-
-	  If unsure, say N.
-
-config HARDWARE_PM
-	tristate "Hardware Performance Monitor Profiling"
-	depends on PROFILING
-	help
-	  take use of hardware performance monitor to profiling the kernel
-	  and application.
-
-	  If unsure, say N.
-
-endmenu
Index: linux-2.6-lttng/arch/i386/oprofile/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/i386/oprofile/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,17 +0,0 @@
-config PROFILING
-	bool "Profiling support (EXPERIMENTAL)"
-	help
-	  Say Y here to enable the extended profiling support mechanisms used
-	  by profilers such as OProfile.
-	  
-
-config OPROFILE
-	tristate "OProfile system profiling (EXPERIMENTAL)"
-	depends on PROFILING
-	help
-	  OProfile is a profiling system capable of profiling the
-	  whole system, include the kernel, kernel modules, libraries,
-	  and applications.
-
-	  If unsure, say N.
-
Index: linux-2.6-lttng/arch/ia64/oprofile/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/ia64/oprofile/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,20 +0,0 @@
-config PROFILING
-	bool "Profiling support (EXPERIMENTAL)"
-	help
-	  Say Y here to enable the extended profiling support mechanisms used
-	  by profilers such as OProfile.
-
-config OPROFILE
-	tristate "OProfile system profiling (EXPERIMENTAL)"
-	depends on PROFILING
-	help
-	  OProfile is a profiling system capable of profiling the
-	  whole system, include the kernel, kernel modules, libraries,
-	  and applications.
-
-	  Due to firmware bugs, you may need to use the "nohalt" boot
-	  option if you're using OProfile with the hardware performance
-	  counters.
-
-	  If unsure, say N.
-
Index: linux-2.6-lttng/arch/m32r/oprofile/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/m32r/oprofile/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,23 +0,0 @@
-
-menu "Profiling support"
-	depends on EXPERIMENTAL
-
-config PROFILING
-	bool "Profiling support (EXPERIMENTAL)"
-	help
-	  Say Y here to enable the extended profiling support mechanisms used
-	  by profilers such as OProfile.
-
-
-config OPROFILE
-	tristate "OProfile system profiling (EXPERIMENTAL)"
-	depends on PROFILING
-	help
-	  OProfile is a profiling system capable of profiling the
-	  whole system, include the kernel, kernel modules, libraries,
-	  and applications.
-
-	  If unsure, say N.
-
-endmenu
-
Index: linux-2.6-lttng/arch/mips/oprofile/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/mips/oprofile/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,23 +0,0 @@
-
-menu "Profiling support"
-	depends on EXPERIMENTAL
-
-config PROFILING
-	bool "Profiling support (EXPERIMENTAL)"
-	help
-	  Say Y here to enable the extended profiling support mechanisms used
-	  by profilers such as OProfile.
-
-
-config OPROFILE
-	tristate "OProfile system profiling (EXPERIMENTAL)"
-	depends on PROFILING && !MIPS_MT_SMTC && EXPERIMENTAL
-	help
-	  OProfile is a profiling system capable of profiling the
-	  whole system, include the kernel, kernel modules, libraries,
-	  and applications.
-
-	  If unsure, say N.
-
-endmenu
-
Index: linux-2.6-lttng/arch/parisc/oprofile/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/parisc/oprofile/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,23 +0,0 @@
-
-menu "Profiling support"
-	depends on EXPERIMENTAL
-
-config PROFILING
-	bool "Profiling support (EXPERIMENTAL)"
-	help
-	  Say Y here to enable the extended profiling support mechanisms used
-	  by profilers such as OProfile.
-	  
-
-config OPROFILE
-	tristate "OProfile system profiling (EXPERIMENTAL)"
-	depends on PROFILING
-	help
-	  OProfile is a profiling system capable of profiling the
-	  whole system, include the kernel, kernel modules, libraries,
-	  and applications.
-
-	  If unsure, say N.
-
-endmenu
-
Index: linux-2.6-lttng/arch/powerpc/oprofile/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/powerpc/oprofile/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,24 +0,0 @@
-config PROFILING
-	bool "Profiling support (EXPERIMENTAL)"
-	help
-	  Say Y here to enable the extended profiling support mechanisms used
-	  by profilers such as OProfile.
-
-
-config OPROFILE
-	tristate "OProfile system profiling (EXPERIMENTAL)"
-	depends on PROFILING
-	help
-	  OProfile is a profiling system capable of profiling the
-	  whole system, include the kernel, kernel modules, libraries,
-	  and applications.
-
-	  If unsure, say N.
-
-config OPROFILE_CELL
-	bool "OProfile for Cell Broadband Engine"
-	depends on (SPU_FS = y && OPROFILE = m) || (SPU_FS = y && OPROFILE = y) || (SPU_FS = m && OPROFILE = m)
-	default y
-	help
-	  Profiling of Cell BE SPUs requires special support enabled
-	  by this option.
Index: linux-2.6-lttng/arch/s390/oprofile/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/s390/oprofile/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,22 +0,0 @@
-
-menu "Profiling support"
-
-config PROFILING
-	bool "Profiling support"
-	help
-	  Say Y here to enable profiling support mechanisms used by
-	  profilers such as readprofile or OProfile.
-
-
-config OPROFILE
-	tristate "OProfile system profiling"
-	depends on PROFILING
-	help
-	  OProfile is a profiling system capable of profiling the
-	  whole system, include the kernel, kernel modules, libraries,
-	  and applications.
-
-	  If unsure, say N.
-
-endmenu
-
Index: linux-2.6-lttng/arch/sh/oprofile/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/sh/oprofile/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,23 +0,0 @@
-
-menu "Profiling support"
-	depends on EXPERIMENTAL
-
-config PROFILING
-	bool "Profiling support (EXPERIMENTAL)"
-	help
-	  Say Y here to enable the extended profiling support mechanisms used
-	  by profilers such as OProfile.
-	  
-
-config OPROFILE
-	tristate "OProfile system profiling (EXPERIMENTAL)"
-	depends on PROFILING
-	help
-	  OProfile is a profiling system capable of profiling the
-	  whole system, include the kernel, kernel modules, libraries,
-	  and applications.
-
-	  If unsure, say N.
-
-endmenu
-
Index: linux-2.6-lttng/arch/sh64/oprofile/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/sh64/oprofile/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,23 +0,0 @@
-
-menu "Profiling support"
-	depends on EXPERIMENTAL
-
-config PROFILING
-	bool "Profiling support (EXPERIMENTAL)"
-	help
-	  Say Y here to enable the extended profiling support mechanisms used
-	  by profilers such as OProfile.
-
-
-config OPROFILE
-	tristate "OProfile system profiling (EXPERIMENTAL)"
-	depends on PROFILING
-	help
-	  OProfile is a profiling system capable of profiling the
-	  whole system, include the kernel, kernel modules, libraries,
-	  and applications.
-
-	  If unsure, say N.
-
-endmenu
-
Index: linux-2.6-lttng/arch/sparc/oprofile/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/sparc/oprofile/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,17 +0,0 @@
-config PROFILING
-	bool "Profiling support (EXPERIMENTAL)"
-	help
-	  Say Y here to enable the extended profiling support mechanisms used
-	  by profilers such as OProfile.
-	  
-
-config OPROFILE
-	tristate "OProfile system profiling (EXPERIMENTAL)"
-	depends on PROFILING
-	help
-	  OProfile is a profiling system capable of profiling the
-	  whole system, include the kernel, kernel modules, libraries,
-	  and applications.
-
-	  If unsure, say N.
-
Index: linux-2.6-lttng/arch/sparc64/oprofile/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/sparc64/oprofile/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,17 +0,0 @@
-config PROFILING
-	bool "Profiling support (EXPERIMENTAL)"
-	help
-	  Say Y here to enable the extended profiling support mechanisms used
-	  by profilers such as OProfile.
-	  
-
-config OPROFILE
-	tristate "OProfile system profiling (EXPERIMENTAL)"
-	depends on PROFILING
-	help
-	  OProfile is a profiling system capable of profiling the
-	  whole system, include the kernel, kernel modules, libraries,
-	  and applications.
-
-	  If unsure, say N.
-
Index: linux-2.6-lttng/arch/x86_64/oprofile/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/x86_64/oprofile/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ /dev/null	1970-01-01 00:00:00.000000000 +0000
@@ -1,17 +0,0 @@
-config PROFILING
-	bool "Profiling support (EXPERIMENTAL)"
-	help
-	  Say Y here to enable the extended profiling support mechanisms used
-	  by profilers such as OProfile.
-	  
-
-config OPROFILE
-	tristate "OProfile system profiling (EXPERIMENTAL)"
-	depends on PROFILING
-	help
-	  OProfile is a profiling system capable of profiling the
-	  whole system, include the kernel, kernel modules, libraries,
-	  and applications.
-
-	  If unsure, say N.
-
Index: linux-2.6-lttng/kernel/Kconfig.instrumentation
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-lttng/kernel/Kconfig.instrumentation	2007-09-24 10:59:28.000000000 -0400
@@ -0,0 +1,40 @@
+menuconfig INSTRUMENTATION
+	bool "Instrumentation Support"
+	default y
+	---help---
+	  Say Y here to get to see options related to performance measurement,
+	  debugging, and testing. This option alone does not add any kernel code.
+
+	  If you say N, all options in this submenu will be skipped and disabled.
+
+if INSTRUMENTATION
+
+config PROFILING
+	bool "Profiling support (EXPERIMENTAL)"
+	help
+	  Say Y here to enable the extended profiling support mechanisms used
+	  by profilers such as OProfile.
+
+config OPROFILE
+	tristate "OProfile system profiling (EXPERIMENTAL)"
+	depends on PROFILING
+	depends on ALPHA || ARM || BLACKFIN || X86_32 || IA64 || M32R || MIPS || PARISC || PPC || S390 || SUPERH || SPARC || X86_64
+	help
+	  OProfile is a profiling system capable of profiling the
+	  whole system, include the kernel, kernel modules, libraries,
+	  and applications.
+
+	  If unsure, say N.
+
+config KPROBES
+	bool "Kprobes"
+	depends on KALLSYMS && MODULES
+	depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
+	help
+	  Kprobes allows you to trap at almost any kernel address and
+	  execute a callback function.  register_kprobe() establishes
+	  a probepoint and specifies the callback.  Kprobes is useful
+	  for kernel debugging, non-intrusive instrumentation and testing.
+	  If in doubt, say "N".
+
+endif # INSTRUMENTATION
Index: linux-2.6-lttng/arch/i386/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/i386/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ linux-2.6-lttng/arch/i386/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -1251,30 +1251,7 @@ source "drivers/Kconfig"
 
 source "fs/Kconfig"
 
-menuconfig INSTRUMENTATION
-	bool "Instrumentation Support"
-	default y
-	---help---
-	  Say Y here to get to see options related to performance measurement,
-	  debugging, and testing. This option alone does not add any kernel code.
-
-	  If you say N, all options in this submenu will be skipped and disabled.
-
-if INSTRUMENTATION
-
-source "arch/i386/oprofile/Kconfig"
-
-config KPROBES
-	bool "Kprobes"
-	depends on KALLSYMS && MODULES
-	help
-	  Kprobes allows you to trap at almost any kernel address and
-	  execute a callback function.  register_kprobe() establishes
-	  a probepoint and specifies the callback.  Kprobes is useful
-	  for kernel debugging, non-intrusive instrumentation and testing.
-	  If in doubt, say "N".
-
-endif # INSTRUMENTATION
+source "kernel/Kconfig.instrumentation"
 
 source "arch/i386/Kconfig.debug"
 
Index: linux-2.6-lttng/arch/alpha/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/alpha/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ linux-2.6-lttng/arch/alpha/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -654,7 +654,7 @@ source "drivers/Kconfig"
 
 source "fs/Kconfig"
 
-source "arch/alpha/oprofile/Kconfig"
+source "kernel/Kconfig.instrumentation"
 
 source "arch/alpha/Kconfig.debug"
 
Index: linux-2.6-lttng/arch/arm/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/arm/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ linux-2.6-lttng/arch/arm/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -1061,7 +1061,7 @@ endmenu
 
 source "fs/Kconfig"
 
-source "arch/arm/oprofile/Kconfig"
+source "kernel/Kconfig.instrumentation"
 
 source "arch/arm/Kconfig.debug"
 
Index: linux-2.6-lttng/arch/blackfin/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/blackfin/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ linux-2.6-lttng/arch/blackfin/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -914,7 +914,7 @@ source "drivers/Kconfig"
 
 source "fs/Kconfig"
 
-source "arch/blackfin/oprofile/Kconfig"
+source "kernel/Kconfig.instrumentation"
 
 menu "Kernel hacking"
 
Index: linux-2.6-lttng/arch/cris/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/cris/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ linux-2.6-lttng/arch/cris/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -196,6 +196,8 @@ source "sound/Kconfig"
 
 source "drivers/usb/Kconfig"
 
+source "kernel/Kconfig.instrumentation"
+
 source "arch/cris/Kconfig.debug"
 
 source "security/Kconfig"
Index: linux-2.6-lttng/arch/frv/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/frv/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ linux-2.6-lttng/arch/frv/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -375,6 +375,8 @@ source "drivers/Kconfig"
 
 source "fs/Kconfig"
 
+source "kernel/Kconfig.instrumentation"
+
 source "arch/frv/Kconfig.debug"
 
 source "security/Kconfig"
Index: linux-2.6-lttng/arch/h8300/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/h8300/Kconfig	2007-09-24 10:59:28.000000000 -0400
+++ linux-2.6-lttng/arch/h8300/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -223,6 +223,8 @@ endmenu
 
 source "fs/Kconfig"
 
+source "kernel/Kconfig.instrumentation"
+
 source "arch/h8300/Kconfig.debug"
 
 source "security/Kconfig"
Index: linux-2.6-lttng/arch/ia64/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/ia64/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ linux-2.6-lttng/arch/ia64/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -579,20 +579,7 @@ config IRQ_PER_CPU
 
 source "arch/ia64/hp/sim/Kconfig"
 
-menu "Instrumentation Support"
-
-source "arch/ia64/oprofile/Kconfig"
-
-config KPROBES
-	bool "Kprobes"
-	depends on KALLSYMS && MODULES
-	help
-	  Kprobes allows you to trap at almost any kernel address and
-	  execute a callback function.  register_kprobe() establishes
-	  a probepoint and specifies the callback.  Kprobes is useful
-	  for kernel debugging, non-intrusive instrumentation and testing.
-	  If in doubt, say "N".
-endmenu
+source "kernel/Kconfig.instrumentation"
 
 source "arch/ia64/Kconfig.debug"
 
Index: linux-2.6-lttng/arch/m32r/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/m32r/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ linux-2.6-lttng/arch/m32r/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -426,7 +426,7 @@ source "drivers/Kconfig"
 
 source "fs/Kconfig"
 
-source "arch/m32r/oprofile/Kconfig"
+source "kernel/Kconfig.instrumentation"
 
 source "arch/m32r/Kconfig.debug"
 
Index: linux-2.6-lttng/arch/m68k/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/m68k/Kconfig	2007-09-24 10:59:28.000000000 -0400
+++ linux-2.6-lttng/arch/m68k/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -683,6 +683,8 @@ endmenu
 
 source "fs/Kconfig"
 
+source "kernel/Kconfig.instrumentation"
+
 source "arch/m68k/Kconfig.debug"
 
 source "security/Kconfig"
Index: linux-2.6-lttng/arch/m68knommu/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/m68knommu/Kconfig	2007-09-24 10:59:28.000000000 -0400
+++ linux-2.6-lttng/arch/m68knommu/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -696,6 +696,8 @@ source "drivers/Kconfig"
 
 source "fs/Kconfig"
 
+source "kernel/Kconfig.instrumentation"
+
 source "arch/m68knommu/Kconfig.debug"
 
 source "security/Kconfig"
Index: linux-2.6-lttng/arch/mips/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/mips/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ linux-2.6-lttng/arch/mips/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -1961,7 +1961,7 @@ source "drivers/Kconfig"
 
 source "fs/Kconfig"
 
-source "arch/mips/oprofile/Kconfig"
+source "kernel/Kconfig.instrumentation"
 
 source "arch/mips/Kconfig.debug"
 
Index: linux-2.6-lttng/arch/parisc/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/parisc/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ linux-2.6-lttng/arch/parisc/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -267,7 +267,7 @@ source "drivers/Kconfig"
 
 source "fs/Kconfig"
 
-source "arch/parisc/oprofile/Kconfig"
+source "kernel/Kconfig.instrumentation"
 
 source "arch/parisc/Kconfig.debug"
 
Index: linux-2.6-lttng/arch/powerpc/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/powerpc/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ linux-2.6-lttng/arch/powerpc/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -638,20 +638,7 @@ source "arch/powerpc/sysdev/qe_lib/Kconf
 
 source "lib/Kconfig"
 
-menu "Instrumentation Support"
-
-source "arch/powerpc/oprofile/Kconfig"
-
-config KPROBES
-	bool "Kprobes"
-	depends on !BOOKE && !4xx && KALLSYMS && MODULES
-	help
-	  Kprobes allows you to trap at almost any kernel address and
-	  execute a callback function.  register_kprobe() establishes
-	  a probepoint and specifies the callback.  Kprobes is useful
-	  for kernel debugging, non-intrusive instrumentation and testing.
-	  If in doubt, say "N".
-endmenu
+source "kernel/Kconfig.instrumentation"
 
 source "arch/powerpc/Kconfig.debug"
 
Index: linux-2.6-lttng/arch/ppc/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/ppc/Kconfig	2007-09-24 10:59:28.000000000 -0400
+++ linux-2.6-lttng/arch/ppc/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -1307,7 +1307,7 @@ endmenu
 
 source "lib/Kconfig"
 
-source "arch/powerpc/oprofile/Kconfig"
+source "kernel/Kconfig.instrumentation"
 
 source "arch/ppc/Kconfig.debug"
 
Index: linux-2.6-lttng/arch/s390/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/s390/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ linux-2.6-lttng/arch/s390/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -529,21 +529,7 @@ source "drivers/Kconfig"
 
 source "fs/Kconfig"
 
-menu "Instrumentation Support"
-
-source "arch/s390/oprofile/Kconfig"
-
-config KPROBES
-	bool "Kprobes (EXPERIMENTAL)"
-	depends on EXPERIMENTAL && MODULES
-	help
-	  Kprobes allows you to trap at almost any kernel address and
-	  execute a callback function.	register_kprobe() establishes
-	  a probepoint and specifies the callback.  Kprobes is useful
-	  for kernel debugging, non-intrusive instrumentation and testing.
-	  If in doubt, say "N".
-
-endmenu
+source "kernel/Kconfig.instrumentation"
 
 source "arch/s390/Kconfig.debug"
 
Index: linux-2.6-lttng/arch/sh/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/sh/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ linux-2.6-lttng/arch/sh/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -749,7 +749,7 @@ source "drivers/Kconfig"
 
 source "fs/Kconfig"
 
-source "arch/sh/oprofile/Kconfig"
+source "kernel/Kconfig.instrumentation"
 
 source "arch/sh/Kconfig.debug"
 
Index: linux-2.6-lttng/arch/sh64/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/sh64/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ linux-2.6-lttng/arch/sh64/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -285,7 +285,7 @@ source "drivers/Kconfig"
 
 source "fs/Kconfig"
 
-source "arch/sh64/oprofile/Kconfig"
+source "kernel/Kconfig.instrumentation"
 
 source "arch/sh64/Kconfig.debug"
 
Index: linux-2.6-lttng/arch/sparc/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/sparc/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ linux-2.6-lttng/arch/sparc/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -320,11 +320,7 @@ endmenu
 
 source "fs/Kconfig"
 
-menu "Instrumentation Support"
-
-source "arch/sparc/oprofile/Kconfig"
-
-endmenu
+source "kernel/Kconfig.instrumentation"
 
 source "arch/sparc/Kconfig.debug"
 
Index: linux-2.6-lttng/arch/sparc64/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/sparc64/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ linux-2.6-lttng/arch/sparc64/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -460,20 +460,7 @@ source "drivers/fc4/Kconfig"
 
 source "fs/Kconfig"
 
-menu "Instrumentation Support"
-
-source "arch/sparc64/oprofile/Kconfig"
-
-config KPROBES
-	bool "Kprobes (EXPERIMENTAL)"
-	depends on KALLSYMS && EXPERIMENTAL && MODULES
-	help
-	  Kprobes allows you to trap at almost any kernel address and
-	  execute a callback function.  register_kprobe() establishes
-	  a probepoint and specifies the callback.  Kprobes is useful
-	  for kernel debugging, non-intrusive instrumentation and testing.
-	  If in doubt, say "N".
-endmenu
+source "kernel/Kconfig.instrumentation"
 
 source "arch/sparc64/Kconfig.debug"
 
Index: linux-2.6-lttng/arch/um/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/um/Kconfig	2007-09-24 10:59:28.000000000 -0400
+++ linux-2.6-lttng/arch/um/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -289,4 +289,6 @@ config INPUT
 	bool
 	default n
 
+source "kernel/Kconfig.instrumentation"
+
 source "arch/um/Kconfig.debug"
Index: linux-2.6-lttng/arch/v850/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/v850/Kconfig	2007-09-24 10:59:28.000000000 -0400
+++ linux-2.6-lttng/arch/v850/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -331,6 +331,8 @@ source "sound/Kconfig"
 
 source "drivers/usb/Kconfig"
 
+source "kernel/Kconfig.instrumentation"
+
 source "arch/v850/Kconfig.debug"
 
 source "security/Kconfig"
Index: linux-2.6-lttng/arch/x86_64/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/x86_64/Kconfig	2007-09-24 10:59:27.000000000 -0400
+++ linux-2.6-lttng/arch/x86_64/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -833,20 +833,7 @@ source "drivers/firmware/Kconfig"
 
 source fs/Kconfig
 
-menu "Instrumentation Support"
-
-source "arch/x86_64/oprofile/Kconfig"
-
-config KPROBES
-	bool "Kprobes"
-	depends on KALLSYMS && MODULES
-	help
-	  Kprobes allows you to trap at almost any kernel address and
-	  execute a callback function.  register_kprobe() establishes
-	  a probepoint and specifies the callback.  Kprobes is useful
-	  for kernel debugging, non-intrusive instrumentation and testing.
-	  If in doubt, say "N".
-endmenu
+source "kernel/Kconfig.instrumentation"
 
 source "arch/x86_64/Kconfig.debug"
 
Index: linux-2.6-lttng/arch/xtensa/Kconfig
===================================================================
--- linux-2.6-lttng.orig/arch/xtensa/Kconfig	2007-09-24 10:59:28.000000000 -0400
+++ linux-2.6-lttng/arch/xtensa/Kconfig	2007-09-24 10:59:28.000000000 -0400
@@ -251,6 +251,8 @@ config EMBEDDED_RAMDISK_IMAGE
 	  provide one yourself.
 endmenu
 
+source "kernel/Kconfig.instrumentation"
+
 source "arch/xtensa/Kconfig.debug"
 
 source "security/Kconfig"

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

[patch 4/7] Linux Kernel Markers - Architecture Independent Code

[Mathieu Desnoyers]

[-- Attachment #1: linux-kernel-markers-architecture-independent-code.patch --]
[-- Type: text/plain, Size: 27856 bytes --]

The marker activation functions sits in kernel/marker.c. A hash table is used
to keep track of the registered probes and armed markers, so the markers within
a newly loaded module that should be active can be activated at module load
time.

marker_query has been removed. marker_get_first, marker_get_next and
marker_release should be used as iterators on the markers.

Changelog:
- markers_mutex now nests inside module_mutex rather than the opposite.
- Iteration on modules is now done in module.c.
- module_mutex is not exported anymore.
- Don't declare a __markers_strings section.
- Simplified: do not use immediate values, just a simple variable read.
  (removed dependency on immediate values).
- Removed the args field in the marker structure : it was not used.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Acked-by: "Frank Ch. Eigler" <fche@redhat.com>
CC: Christoph Hellwig <hch@infradead.org>
CC: Rusty Russell <rusty@rustcorp.com.au>
---

 include/asm-generic/vmlinux.lds.h |    7 
 include/linux/marker.h            |  142 ++++++++
 include/linux/module.h            |   18 +
 kernel/marker.c                   |  607 ++++++++++++++++++++++++++++++++++++++
 kernel/module.c                   |   64 +++-
 5 files changed, 836 insertions(+), 2 deletions(-)

Index: linux-2.6-lttng/include/asm-generic/vmlinux.lds.h
===================================================================
--- linux-2.6-lttng.orig/include/asm-generic/vmlinux.lds.h	2007-09-21 14:47:16.000000000 -0400
+++ linux-2.6-lttng/include/asm-generic/vmlinux.lds.h	2007-09-21 14:47:30.000000000 -0400
@@ -12,7 +12,11 @@
 /* .data section */
 #define DATA_DATA							\
 	*(.data)							\
-	*(.data.init.refok)
+	*(.data.init.refok)						\
+	. = ALIGN(8);							\
+	VMLINUX_SYMBOL(__start___markers) = .;				\
+	*(__markers)							\
+	VMLINUX_SYMBOL(__stop___markers) = .;
 
 #define RO_DATA(align)							\
 	. = ALIGN((align));						\
@@ -20,6 +24,7 @@
 		VMLINUX_SYMBOL(__start_rodata) = .;			\
 		*(.rodata) *(.rodata.*)					\
 		*(__vermagic)		/* Kernel version magic */	\
+		*(__markers_strings)	/* Markers: strings */		\
 	}								\
 									\
 	.rodata1          : AT(ADDR(.rodata1) - LOAD_OFFSET) {		\
Index: linux-2.6-lttng/include/linux/marker.h
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-lttng/include/linux/marker.h	2007-09-21 15:04:46.000000000 -0400
@@ -0,0 +1,142 @@
+#ifndef _LINUX_MARKER_H
+#define _LINUX_MARKER_H
+
+/*
+ * Code markup for dynamic and static tracing.
+ *
+ * See Documentation/marker.txt.
+ *
+ * (C) Copyright 2006 Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
+ *
+ * This file is released under the GPLv2.
+ * See the file COPYING for more details.
+ */
+
+#include <linux/types.h>
+
+struct module;
+struct __mark_marker;
+
+/**
+ * marker_probe_func - Type of a marker probe function
+ * @mdata: pointer of type struct __mark_marker
+ * @private_data: caller site private data
+ * @fmt: format string
+ * @...: variable argument list
+ *
+ * Type of marker probe functions. They receive the mdata and need to parse the
+ * format string to recover the variable argument list.
+ */
+typedef void marker_probe_func(const struct __mark_marker *mdata,
+	void *private_data, const char *fmt, ...);
+
+struct __mark_marker {
+	const char *name;	/* Marker name */
+	const char *format;	/* Marker format string, describing the
+				 * variable argument list.
+				 */
+	char state;		/* Marker state. */
+	marker_probe_func *call;/* Probe handler function pointer */
+	void *pdata;		/* Private probe data */
+} __attribute__((aligned(8)));
+
+#ifdef CONFIG_MARKERS
+
+/*
+ * Note : the empty asm volatile with read constraint is used here instead of a
+ * "used" attribute to fix a gcc 4.1.x bug.
+ * Make sure the alignment of the structure in the __markers section will
+ * 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(name, call_data, format, args...)			\
+	do {								\
+		static const char __mstrtab_name_##name[]		\
+		__attribute__((section("__markers_strings")))		\
+		= #name;						\
+		static const char __mstrtab_format_##name[]		\
+		__attribute__((section("__markers_strings")))		\
+		= format;						\
+		static struct __mark_marker __mark_##name		\
+		__attribute__((section("__markers"))) =			\
+		{ __mstrtab_name_##name, __mstrtab_format_##name,	\
+		0, __mark_empty_function, NULL };			\
+		asm volatile ( "" : : "i" (&__mark_##name));		\
+		__mark_check_format(format, ## args);			\
+		if (unlikely(__mark_##name.state)) {			\
+			preempt_disable();				\
+			(*__mark_##name.call)				\
+				(&__mark_##name, call_data,		\
+				format, ## args);			\
+			preempt_enable();				\
+		}							\
+	} while (0)
+
+extern void marker_update_probe_range(struct __mark_marker *begin,
+	struct __mark_marker *end, struct module *probe_module, int *refcount);
+#else /* !CONFIG_MARKERS */
+#define __trace_mark(name, call_data, format, args...) \
+		__mark_check_format(format, ## args)
+static inline void marker_update_probe_range(struct __mark_marker *begin,
+	struct __mark_marker *end, struct module *probe_module, int *refcount)
+{ }
+#endif /* CONFIG_MARKERS */
+
+/**
+ * trace_mark - Marker
+ * @name: marker name, not quoted.
+ * @format: format string
+ * @args...: variable argument list
+ *
+ * Places a marker.
+ */
+#define trace_mark(name, format, args...) \
+	__trace_mark(name, NULL, format, ## args)
+
+#define MARK_MAX_FORMAT_LEN	1024
+
+/**
+ * MARK_NOARGS - Format string for a marker with no argument.
+ */
+#define MARK_NOARGS " "
+
+/* To be used for string format validity checking with gcc */
+static inline void __attribute__ ((format (printf, 1, 2)))
+	__mark_check_format(const char *fmt, ...) { }
+
+extern marker_probe_func __mark_empty_function;
+
+/*
+ * Connect a probe to a marker.
+ * pdata must be a valid allocated memory address, or NULL.
+ */
+extern int marker_probe_register(const char *name, const char *format,
+				marker_probe_func *probe, void *pdata);
+
+/*
+ * Returns the pdata given to marker_probe_register.
+ */
+extern void *marker_probe_unregister(const char *name);
+/*
+ * Unregister a marker by providing the registered pdata.
+ */
+extern void *marker_probe_unregister_pdata(void *pdata);
+
+extern int marker_arm(const char *name);
+extern int marker_disarm(const char *name);
+
+struct marker_iter {
+	struct module *module;
+	struct __mark_marker *marker;
+};
+
+extern void marker_iter_start(struct marker_iter *iter);
+extern void marker_iter_next(struct marker_iter *iter);
+extern void marker_iter_stop(struct marker_iter *iter);
+extern void marker_iter_reset(struct marker_iter *iter);
+extern void *marker_get_pdata(const char *name);
+extern int marker_get_iter_range(struct __mark_marker **marker,
+	struct __mark_marker *begin,
+	struct __mark_marker *end);
+
+#endif
Index: linux-2.6-lttng/include/linux/module.h
===================================================================
--- linux-2.6-lttng.orig/include/linux/module.h	2007-09-21 14:47:16.000000000 -0400
+++ linux-2.6-lttng/include/linux/module.h	2007-09-21 14:47:30.000000000 -0400
@@ -15,6 +15,7 @@
 #include <linux/stringify.h>
 #include <linux/kobject.h>
 #include <linux/moduleparam.h>
+#include <linux/marker.h>
 #include <asm/local.h>
 
 #include <asm/module.h>
@@ -370,6 +371,10 @@ struct module
 	/* The command line arguments (may be mangled).  People like
 	   keeping pointers to this stuff */
 	char *args;
+#ifdef CONFIG_MARKERS
+	struct __mark_marker *markers;
+	unsigned int num_markers;
+#endif
 };
 #ifndef MODULE_ARCH_INIT
 #define MODULE_ARCH_INIT {}
@@ -473,6 +478,9 @@ int unregister_module_notifier(struct no
 
 extern void print_modules(void);
 
+extern void module_update_markers(struct module *probe_module, int *refcount);
+extern int module_get_iter_markers(struct marker_iter *iter);
+
 #else /* !CONFIG_MODULES... */
 #define EXPORT_SYMBOL(sym)
 #define EXPORT_SYMBOL_GPL(sym)
@@ -572,6 +580,16 @@ static inline void print_modules(void)
 {
 }
 
+static inline void module_update_markers(struct module *probe_module,
+		int *refcount)
+{
+}
+
+static inline int module_get_iter_markers(struct marker_iter *iter)
+{
+	return 0;
+}
+
 #endif /* CONFIG_MODULES */
 
 struct device_driver;
Index: linux-2.6-lttng/kernel/module.c
===================================================================
--- linux-2.6-lttng.orig/kernel/module.c	2007-09-21 14:47:30.000000000 -0400
+++ linux-2.6-lttng/kernel/module.c	2007-09-21 14:47:30.000000000 -0400
@@ -1718,6 +1718,8 @@ static struct module *load_module(void _
 	unsigned int unusedcrcindex;
 	unsigned int unusedgplindex;
 	unsigned int unusedgplcrcindex;
+	unsigned int markersindex;
+	unsigned int markersstringsindex;
 	struct module *mod;
 	long err = 0;
 	void *percpu = NULL, *ptr = NULL; /* Stops spurious gcc warning */
@@ -1983,6 +1985,8 @@ static struct module *load_module(void _
 		add_taint_module(mod, TAINT_FORCED_MODULE);
 	}
 #endif
+	markersindex = find_sec(hdr, sechdrs, secstrings, "__markers");
+ 	markersstringsindex = find_sec(hdr, sechdrs, secstrings, "__markers_strings");
 
 	/* Now do relocations. */
 	for (i = 1; i < hdr->e_shnum; i++) {
@@ -2005,6 +2009,11 @@ static struct module *load_module(void _
 		if (err < 0)
 			goto cleanup;
 	}
+#ifdef CONFIG_MARKERS
+	mod->markers = (void *)sechdrs[markersindex].sh_addr;
+	mod->num_markers =
+		sechdrs[markersindex].sh_size / sizeof(*mod->markers);
+#endif
 
         /* Find duplicate symbols */
 	err = verify_export_symbols(mod);
@@ -2028,7 +2037,11 @@ static struct module *load_module(void _
 	 if (err < 0)
 		 goto nomodsectinfo;
 #endif
-
+#ifdef CONFIG_MARKERS
+	if (!mod->taints)
+		marker_update_probe_range(mod->markers,
+			mod->markers + mod->num_markers, NULL, NULL);
+#endif
 	err = module_finalize(hdr, sechdrs, mod);
 	if (err < 0)
 		goto cleanup;
@@ -2644,3 +2657,52 @@ EXPORT_SYMBOL(module_remove_driver);
 void struct_module(struct module *mod) { return; }
 EXPORT_SYMBOL(struct_module);
 #endif
+
+#ifdef CONFIG_MARKERS
+void module_update_markers(struct module *probe_module, int *refcount)
+{
+	struct module *mod;
+
+	mutex_lock(&module_mutex);
+	list_for_each_entry(mod, &modules, list)
+		if (!mod->taints)
+			marker_update_probe_range(mod->markers,
+				mod->markers + mod->num_markers,
+				probe_module, refcount);
+	mutex_unlock(&module_mutex);
+}
+EXPORT_SYMBOL_GPL(module_update_markers);
+
+/*
+ * Returns 0 if current not found.
+ * Returns 1 if current found.
+ */
+int module_get_iter_markers(struct marker_iter *iter)
+{
+	struct module *iter_mod;
+	int found = 0;
+
+	mutex_lock(&module_mutex);
+	list_for_each_entry(iter_mod, &modules, list) {
+		if (!iter_mod->taints) {
+			/*
+			 * Sorted module list
+			 */
+			if (iter_mod < iter->module)
+				continue;
+			else if (iter_mod > iter->module)
+				iter->marker = NULL;
+			found = marker_get_iter_range(&iter->marker,
+				iter_mod->markers,
+				iter_mod->markers + iter_mod->num_markers);
+			if (found) {
+				iter->module = iter_mod;
+				break;
+			}
+		}
+	}
+	mutex_unlock(&module_mutex);
+	return found;
+}
+EXPORT_SYMBOL_GPL(module_get_iter_markers);
+#endif
Index: linux-2.6-lttng/kernel/marker.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-lttng/kernel/marker.c	2007-09-21 14:47:30.000000000 -0400
@@ -0,0 +1,607 @@
+/*
+ * Copyright (C) 2007 Mathieu Desnoyers
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ */
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/types.h>
+#include <linux/jhash.h>
+#include <linux/list.h>
+#include <linux/rcupdate.h>
+#include <linux/marker.h>
+#include <linux/err.h>
+
+extern struct __mark_marker __start___markers[];
+extern struct __mark_marker __stop___markers[];
+
+/*
+ * module_mutex nests inside markers_mutex. Markers mutex protects the builtin
+ * and module markers, the hash table and deferred_sync.
+ */
+DEFINE_MUTEX(markers_mutex);
+
+/*
+ * Marker deferred synchronization.
+ * Upon marker probe_unregister, we delay call to synchronize_sched() to
+ * accelerate mass unregistration (only when there is no more reference to a
+ * given module do we call synchronize_sched()). However, we need to make sure
+ * every critical region has ended before we re-arm a marker that has been
+ * unregistered and then registered back with a different probe data.
+ */
+static int deferred_sync;
+
+/*
+ * Marker hash table, containing the active markers.
+ * Protected by module_mutex.
+ */
+#define MARKER_HASH_BITS 6
+#define MARKER_TABLE_SIZE (1 << MARKER_HASH_BITS)
+
+struct marker_entry {
+	struct hlist_node hlist;
+	char *format;
+	marker_probe_func *probe;
+	void *pdata;
+	int refcount;	/* Number of times armed. 0 if disarmed. */
+	char name[0];	/* Contains name'\0'format'\0' */
+};
+
+static struct hlist_head marker_table[MARKER_TABLE_SIZE];
+
+/**
+ * __mark_empty_function - Empty probe callback
+ * @mdata: pointer of type const struct __mark_marker
+ * @fmt: format string
+ * @...: variable argument list
+ *
+ * Empty callback provided as a probe to the markers. By providing this to a
+ * disabled marker, we make sure the  execution flow is always valid even
+ * though the function pointer change and the marker enabling are two distinct
+ * operations that modifies the execution flow of preemptible code.
+ */
+void __mark_empty_function(const struct __mark_marker *mdata,
+	void *private_data,
+	const char *fmt, ...)
+{ }
+EXPORT_SYMBOL_GPL(__mark_empty_function);
+
+/*
+ * Get marker if the marker is present in the marker hash table.
+ * Must be called with markers_mutex held.
+ * Returns NULL if not present.
+ */
+static struct marker_entry *get_marker(const char *name)
+{
+	struct hlist_head *head;
+	struct hlist_node *node;
+	struct marker_entry *e;
+	u32 hash = jhash(name, strlen(name), 0);
+
+	head = &marker_table[hash & ((1 << MARKER_HASH_BITS)-1)];
+	hlist_for_each_entry(e, node, head, hlist) {
+		if (!strcmp(name, e->name))
+			return e;
+	}
+	return NULL;
+}
+
+/*
+ * Add the marker to the marker hash table. Must be called with markers_mutex
+ * held.
+ */
+static int add_marker(const char *name,
+	const char *format, marker_probe_func *probe, void *pdata)
+{
+	struct hlist_head *head;
+	struct hlist_node *node;
+	struct marker_entry *e;
+	size_t name_len = strlen(name) + 1;
+	size_t format_len = 0;
+	u32 hash = jhash(name, name_len-1, 0);
+
+	if (format)
+		format_len = strlen(format) + 1;
+	head = &marker_table[hash & ((1 << MARKER_HASH_BITS)-1)];
+	hlist_for_each_entry(e, node, head, hlist) {
+		if (!strcmp(name, e->name)) {
+			printk(KERN_NOTICE
+				"Marker %s busy, probe %p already installed\n",
+				name, e->probe);
+			return -EBUSY;	/* Already there */
+		}
+	}
+	/*
+	 * Using kmalloc here to allocate a variable length element. Could
+	 * cause some memory fragmentation if overused.
+	 */
+	e = kmalloc(sizeof(struct marker_entry) + name_len + format_len,
+			GFP_KERNEL);
+	if (!e)
+		return -ENOMEM;
+	memcpy(&e->name[0], name, name_len);
+	if (format) {
+		e->format = &e->name[name_len];
+		memcpy(e->format, format, format_len);
+		trace_mark(core_marker_format, "name %s format %s",
+				e->name, e->format);
+	} else
+		e->format = NULL;
+	e->probe = probe;
+	e->pdata = pdata;
+	e->refcount = 0;
+	hlist_add_head(&e->hlist, head);
+	return 0;
+}
+
+/*
+ * Remove the marker from the marker hash table. Must be called with mutex_lock
+ * held.
+ */
+static void *remove_marker(const char *name)
+{
+	struct hlist_head *head;
+	struct hlist_node *node;
+	struct marker_entry *e;
+	int found = 0;
+	size_t len = strlen(name) + 1;
+	void *pdata = NULL;
+	u32 hash = jhash(name, len-1, 0);
+
+	head = &marker_table[hash & ((1 << MARKER_HASH_BITS)-1)];
+	hlist_for_each_entry(e, node, head, hlist) {
+		if (!strcmp(name, e->name)) {
+			found = 1;
+			break;
+		}
+	}
+	if (found) {
+		pdata = e->pdata;
+		hlist_del(&e->hlist);
+		kfree(e);
+	}
+	return pdata;
+}
+
+/*
+ * Set the mark_entry format to the format found in the element.
+ */
+static int marker_set_format(struct marker_entry **entry, const char *format)
+{
+	struct marker_entry *e;
+	size_t name_len = strlen((*entry)->name) + 1;
+	size_t format_len = strlen(format) + 1;
+
+	e = kmalloc(sizeof(struct marker_entry) + name_len + format_len,
+			GFP_KERNEL);
+	if (!e)
+		return -ENOMEM;
+	memcpy(&e->name[0], (*entry)->name, name_len);
+	e->format = &e->name[name_len];
+	memcpy(e->format, format, format_len);
+	e->probe = (*entry)->probe;
+	e->pdata = (*entry)->pdata;
+	e->refcount = (*entry)->refcount;
+	hlist_add_before(&e->hlist, &(*entry)->hlist);
+	hlist_del(&(*entry)->hlist);
+	kfree(*entry);
+	*entry = e;
+	trace_mark(core_marker_format, "name %s format %s",
+			e->name, e->format);
+	return 0;
+}
+
+/*
+ * Sets the probe callback corresponding to one marker.
+ */
+static int set_marker(struct marker_entry **entry,
+			struct __mark_marker *elem)
+{
+	int ret;
+	WARN_ON(strcmp((*entry)->name, elem->name) != 0);
+
+	if ((*entry)->format) {
+		if (strcmp((*entry)->format, elem->format) != 0) {
+			printk(KERN_NOTICE
+				"Format mismatch for probe %s "
+				"(%s), marker (%s)\n",
+				(*entry)->name,
+				(*entry)->format,
+				elem->format);
+			return -EPERM;
+		}
+	} else {
+		ret = marker_set_format(entry, elem->format);
+		if (ret)
+			return ret;
+	}
+	elem->call = (*entry)->probe;
+	elem->pdata = (*entry)->pdata;
+	elem->state = 1;
+	return 0;
+}
+
+/*
+ * Disable a marker and its probe callback.
+ * Note: only after a synchronize_sched() issued after setting elem->call to the
+ * empty function insures that the original callback is not used anymore. This
+ * insured by preemption disabling around the call site.
+ */
+static void disable_marker(struct __mark_marker *elem)
+{
+	elem->state = 0;
+	elem->call = __mark_empty_function;
+	/*
+	 * Leave the pdata and id there, because removal is racy and should be
+	 * done only after a synchronize_sched(). These are never used until
+	 * the next initialization anyway.
+	 */
+}
+
+/**
+ * marker_update_probe_range - Update a probe range
+ * @begin: beginning of the range
+ * @end: end of the range
+ * @probe_module: module address of the probe being updated
+ * @refcount: number of references left to the given probe_module (out)
+ *
+ * Updates the probe callback corresponding to a range of markers.
+ * Must be called with markers_mutex held.
+ */
+void marker_update_probe_range(
+	struct __mark_marker *begin,
+	struct __mark_marker *end,
+	struct module *probe_module,
+	int *refcount)
+{
+	struct __mark_marker *iter;
+	struct marker_entry *mark_entry;
+
+	for (iter = begin; iter < end; iter++) {
+		mark_entry = get_marker(iter->name);
+		if (mark_entry && mark_entry->refcount) {
+			set_marker(&mark_entry, iter);
+			/*
+			 * ignore error, continue
+			 */
+			if (probe_module)
+				if (probe_module ==
+			__module_text_address((unsigned long)mark_entry->probe))
+					(*refcount)++;
+		} else {
+			disable_marker(iter);
+		}
+	}
+}
+EXPORT_SYMBOL_GPL(marker_update_probe_range);
+
+/*
+ * Update probes, removing the faulty probes.
+ * Issues a synchronize_sched() when no reference to the module passed
+ * as parameter is found in the probes so the probe module can be
+ * safely unloaded from now on.
+ */
+static inline void marker_update_probes(struct module *probe_module)
+{
+	int refcount = 0;
+
+	mutex_lock(&markers_mutex);
+	/* Core kernel markers */
+	marker_update_probe_range(__start___markers,
+			__stop___markers, probe_module, &refcount);
+	/* Markers in modules. */
+	module_update_markers(probe_module, &refcount);
+	if (probe_module && refcount == 0) {
+		synchronize_sched();
+		deferred_sync = 0;
+	}
+	mutex_unlock(&markers_mutex);
+}
+
+/**
+ * marker_probe_register -  Connect a probe to a marker
+ * @name: marker name
+ * @format: format string
+ * @probe: probe handler
+ * @pdata: probe private data
+ *
+ * pdata must be a valid allocated memory address, or NULL.
+ * Returns 0 if ok, error value on error.
+ */
+int marker_probe_register(const char *name, const char *format,
+			marker_probe_func *probe, void *pdata)
+{
+	struct marker_entry *entry;
+	int ret = 0, need_update = 0;
+
+	mutex_lock(&markers_mutex);
+	entry = get_marker(name);
+	if (entry && entry->refcount) {
+		ret = -EBUSY;
+		goto end;
+	}
+	if (deferred_sync) {
+		synchronize_sched();
+		deferred_sync = 0;
+	}
+	ret = add_marker(name, format, probe, pdata);
+	if (ret)
+		goto end;
+	need_update = 1;
+end:
+	mutex_unlock(&markers_mutex);
+	if (need_update)
+		marker_update_probes(NULL);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(marker_probe_register);
+
+/**
+ * marker_probe_unregister -  Disconnect a probe from a marker
+ * @name: marker name
+ *
+ * Returns the pdata given to marker_probe_register, or an ERR_PTR().
+ */
+void *marker_probe_unregister(const char *name)
+{
+	struct module *probe_module;
+	struct marker_entry *entry;
+	void *pdata;
+	int need_update = 0;
+
+	mutex_lock(&markers_mutex);
+	entry = get_marker(name);
+	if (!entry) {
+		pdata = ERR_PTR(-ENOENT);
+		goto end;
+	}
+	entry->refcount = 0;
+	/* In what module is the probe handler ? */
+	probe_module = __module_text_address((unsigned long)entry->probe);
+	pdata = remove_marker(name);
+	deferred_sync = 1;
+	need_update = 1;
+end:
+	mutex_unlock(&markers_mutex);
+	if (need_update)
+		marker_update_probes(probe_module);
+	return pdata;
+}
+EXPORT_SYMBOL_GPL(marker_probe_unregister);
+
+/**
+ * marker_probe_unregister_pdata -  Disconnect a probe from a marker
+ * @pdata: probe private data
+ *
+ * Unregister a marker by providing the registered pdata.
+ * Returns the pdata given to marker_probe_register, or an ERR_PTR().
+ */
+void *marker_probe_unregister_pdata(void *pdata)
+{
+	struct module *probe_module;
+	struct hlist_head *head;
+	struct hlist_node *node;
+	struct marker_entry *entry;
+	int found = 0;
+	unsigned int i;
+	int need_update = 0;
+
+	mutex_lock(&markers_mutex);
+	for (i = 0; i < MARKER_TABLE_SIZE; i++) {
+		head = &marker_table[i];
+		hlist_for_each_entry(entry, node, head, hlist) {
+			if (entry->pdata == pdata) {
+				found = 1;
+				goto iter_end;
+			}
+		}
+	}
+iter_end:
+	if (!found) {
+		pdata = ERR_PTR(-ENOENT);
+		goto end;
+	}
+	entry->refcount = 0;
+	/* In what module is the probe handler ? */
+	probe_module = __module_text_address((unsigned long)entry->probe);
+	pdata = remove_marker(entry->name);
+	deferred_sync = 1;
+	need_update = 1;
+end:
+	mutex_unlock(&markers_mutex);
+	if (need_update)
+		marker_update_probes(probe_module);
+	return pdata;
+}
+EXPORT_SYMBOL_GPL(marker_probe_unregister_pdata);
+
+/**
+ * marker_arm - Arm a marker
+ * @name: marker name
+ *
+ * Activate a marker. It keeps a reference count of the number of
+ * arming/disarming done.
+ * Returns 0 if ok, error value on error.
+ */
+int marker_arm(const char *name)
+{
+	struct marker_entry * entry;
+	int ret = 0, need_update = 0;
+
+	mutex_lock(&markers_mutex);
+	entry = get_marker(name);
+	if (!entry) {
+		ret = -ENOENT;
+		goto end;
+	}
+	/*
+	 * Only need to update probes when refcount passes from 0 to 1.
+	 */
+	if (entry->refcount++)
+		goto end;
+	need_update = 1;
+end:
+	mutex_unlock(&markers_mutex);
+	if (need_update)
+		marker_update_probes(NULL);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(marker_arm);
+
+/**
+ * marker_disarm - Disarm a marker
+ * @name: marker name
+ *
+ * Disarm a marker. It keeps a reference count of the number of arming/disarming
+ * done.
+ * Returns 0 if ok, error value on error.
+ */
+int marker_disarm(const char *name)
+{
+	struct marker_entry * entry;
+	int ret = 0, need_update = 0;
+
+	mutex_lock(&markers_mutex);
+	entry = get_marker(name);
+	if (!entry) {
+		ret = -ENOENT;
+		goto end;
+	}
+	/*
+	 * Only permit decrement refcount if higher than 0.
+	 * Do probe update only on 1 -> 0 transition.
+	 */
+	if (entry->refcount) {
+		if (--entry->refcount)
+			goto end;
+	} else {
+		ret = -EPERM;
+		goto end;
+	}
+	need_update = 1;
+end:
+	mutex_unlock(&markers_mutex);
+	if (need_update)
+		marker_update_probes(NULL);
+	return ret;
+}
+EXPORT_SYMBOL_GPL(marker_disarm);
+
+/**
+ * marker_get_pdata - Get a marker's probe private data
+ * @name: marker name
+ *
+ * Returns the pdata pointer, or an ERR_PTR.
+ * The pdata pointer should _only_ be dereferenced if the caller is the owner of
+ * the data, or its content could vanish. This is mostly used to confirm that a
+ * caller is the owner of a registered probe.
+ */
+void *marker_get_pdata(const char *name)
+{
+	struct hlist_head *head;
+	struct hlist_node *node;
+	struct marker_entry *e;
+	size_t name_len = strlen(name) + 1;
+	u32 hash = jhash(name, name_len-1, 0);
+	int found = 0;
+
+	head = &marker_table[hash & ((1 << MARKER_HASH_BITS)-1)];
+	hlist_for_each_entry(e, node, head, hlist) {
+		if (!strcmp(name, e->name)) {
+			found = 1;
+			return e->pdata;
+		}
+	}
+	return ERR_PTR(-ENOENT);
+}
+EXPORT_SYMBOL_GPL(marker_get_pdata);
+
+/**
+ * marker_get_iter_range - Get a next marker iterator given a range.
+ * @marker: current markers (in), next marker (out)
+ * @begin: beginning of the range
+ * @end: end of the range
+ *
+ * Returns whether a next marker has been found (1) or not (0).
+ * Will return the first marker in the range if the input marker is NULL.
+ */
+int marker_get_iter_range(struct __mark_marker **marker,
+	struct __mark_marker *begin,
+	struct __mark_marker *end)
+{
+	int found = 0;
+
+	if (!*marker && begin != end) {
+		found = 1;
+		*marker = begin;
+	} else if (*marker >= begin && *marker < end) {
+		found = 1;
+		/*
+		 * *marker is known to be a valid marker from now on.
+		 */
+	}
+	return found;
+}
+EXPORT_SYMBOL_GPL(marker_get_iter_range);
+
+static inline void marker_get_iter(struct marker_iter *iter)
+{
+	int found = 0;
+
+	/* Core kernel markers */
+	if (!iter->module) {
+		found = marker_get_iter_range(&iter->marker,
+				__start___markers, __stop___markers);
+		if (found)
+			goto end;
+	}
+	/* Markers in modules. */
+	found = module_get_iter_markers(iter);
+end:
+	if (!found)
+		marker_iter_reset(iter);
+}
+
+void marker_iter_start(struct marker_iter *iter)
+{
+	mutex_lock(&markers_mutex);
+	marker_get_iter(iter);
+}
+EXPORT_SYMBOL_GPL(marker_iter_start);
+
+void marker_iter_next(struct marker_iter *iter)
+{
+	iter->marker++;
+	/*
+	 * iter->marker may be invalid because we blindly incremented it.
+	 * Make sure it is valid by marshalling on the markers, getting the
+	 * markers from following modules if necessary.
+	 */
+	marker_get_iter(iter);
+}
+EXPORT_SYMBOL_GPL(marker_iter_next);
+
+void marker_iter_stop(struct marker_iter *iter)
+{
+	mutex_unlock(&markers_mutex);
+}
+EXPORT_SYMBOL_GPL(marker_iter_stop);
+
+void marker_iter_reset(struct marker_iter *iter)
+{
+	iter->module = NULL;
+	iter->marker = NULL;
+}
+EXPORT_SYMBOL_GPL(marker_iter_reset);

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

[patch 5/7] Linux Kernel Markers - Use instrumentation kconfig menu

[Mathieu Desnoyers]

[-- Attachment #1: linux-kernel-markers-instrumentation-menu.patch --]
[-- Type: text/plain, Size: 11852 bytes --]

With the increasing complexity of today's user-space application and the wide
deployment of SMP systems, the users need an increasing understanding of the
behavior and performance of a system across multiple processes/different
execution contexts/multiple CPUs.  In applications such as large clusters
(Google, IBM), video acquisition (Autodesk), embedded real-time systems (Wind
River, Monta Vista, Sony) or sysadmin/programmer-type tasks (SystemTAP from
Redhat), a tool that permits tracing of kernel-user space interaction becomes
necessary.

Usage of such tools have been made to successfully pinpoint problems such as:
latency issues in a user-space video acquisition application, slowdown
problems in large clusters due to a switch to a different filesystems with a
different cache size, abnormal Linux scheduler latency (just to name a few
that I have personally investigated).

The currently existing solutions does not give a system-wide overview of what
- and when - things are happening on the system.  Ptracing a program works
with few processes, but quickly becomes useless when it comes to keeping track
of many processes.

Bugs occuring because of bad interaction of such complex systems can be very
hard to find due to the fact that they occur rarely (sometimes once a week on
hundreds of machines).  One can therefore only hope at having the best
conditions to statistically reproduce the bug while extracting information
from the system.  Some bugs have been successfully found at Google using their
ktrace tracer only because they could enable it on production machines and
therefore recreate the same context where the bug happened.

Therefore, it makes sense to offer an instrumentation set of the most relevant
events occurring in the Linux that can have the smallest performance cost
possible when not active while not requiring a reboot of a production system
to activate.  This is essentially what the markers are providing.

Since we cannot limit the growth of the Linux kernel, nor can we pre-determine
each and every "interesting" instrumentation within each subsystem and driver,
it is sensible to let this task to the persons who knows the best their code. 
Adding instrumentation should therefore be as easy as adding and maintaining a
"printk" in the kernel code from the developer's point of view.

Towards a complete tracing mechanism in the Linux kernel, the markers are only
one step forward.  The following step is to connect probes to those markers
that will record the tracing information in buffers exported to user-space,
organized in timestamped "events".  Probe callbacks are responsible for
serializing the information passed as parameter to the markers (described by
the format string) into the events.  A control mechanism to activate/stop the
tracing is required, as well as a daemon that maps the buffers to write them
to disk or send them through the network.

Keeping track of the events also requires a centralized infrastructure : the
idea is to assign a unique ID to each event so they can be later recognized in
the trace.  Keeping in mind that recording the complete instrumentation site
name string for each event would be more that inefficient, assigning a numeric
unique identifier makes sense.

Finally, support for gathering events coming from user-space, with a minimal
performance impact, is very useful to see the interaction between the system's
execution contexts.

The last steps are currently implemented in Linux Trace Toolkit Next
Generation (LTTng).

The SystemTAP project could clearly benefit from such an infrastructure for
tracing.  In addition, they would be providing support for dynamic addition of
kernel probes through breakpoints/jumps when possible, with the associated
restrictions (accessing local variables, reentrancy, speed).




This marker infrastructure is a hook-callback mechanism.  It is meant to have
an impact as low as possible on the system performances when no callback
(probe) is connected so markers (hooks) can be compiled into a production
kernel without noticeable slowdown.

Why use the markers instead of kprobes?

The rationale behind this mechanism the following :

1 - It makes sense to have instrumentation (for tracing, profiling)
    within the kernel source tree so that it can follow its evolution.
    Other options, such as kprobes, imply maintaining an external set of
    instrumentation that must be adapted to each kernel version.
    Although it may make sense for distributions, it is not well suited
    for kernel developers, since they rarely work on a major
    distribution image.
2 - kprobes, although being a very good attempt at providing a dynamic
    hooking mechanism that has no impact when disabled, suffers from
    important limitations :
  a - It cannot access local variables of a function at a particular
      point within its body that will be consistent thorough the kernel
      versions without involving a lot of recurrent hair-pulling.
  b - Kprobes is slow, since it involves going though a trap each time
      a probe site is executed. Even though the djprobes project made a
      good effort to make things faster, it cannot currently instrument
      fully-preemptible kernels and does not solve (1), (2a) and (2c).
  c - On the reentrancy side, going though a trap (thus playing with
      interrupt enable/disable) and taking spinlocks are not suited to
      some code paths, i.e. :
      kernel/lockdep.c, printk (within the lockdep_on()/lockdep_off()).
      It must be understood that some code paths interesting for
      instrumentation often present a particular reentrancy challenge.

Some more details :

The probe callback connection to its markers is done dynamically.  A predicted
branch (see the immediate values infrastructure) is used to skip the hook stack
setup and function call when the marker is "disabled" (no probe is connected).
Further optimizations can be implemented for each architecture to make this
branch faster. (see immediate values)

Instrumentation of a subsystem becomes therefore a straightforward task.  One
has to add instrumentation within the key locations of the kernel code in the
following form :

trace_mark(subsystem_event, "%d %p", myint, myptr);


Jim Keniston <jkenisto@us.ibm.com> adds:

kprobes remains a vital foundation for SystemTap.  But markers are attactive
as an alternate source of trace/debug info.  Here's why:

1. Markers will live in the kernel and presumably be kept up to date by
   the maintainers of the enclosing code.  We have a growing set of tapsets
   (probe libraries), each of which "knows" the source code for a certain area
   of the kernel.  Whenever the underlying kernel code changes (e.g., a
   function or one of its args disappears or is renamed), there's a chance
   that the tapset will become invalid until we bring it back in sync with the
   kernel.  As you can imagine, maintaining tapsets separate from the kernel
   source is a maintenance headache.  Markers could mitigate this.

2. Because the kernel code is highly optimized, the kernel's dwarf info
   doesn't always accurately reflect which variables have which values on
   which lines (sometimes even upon entry to a function).  A marker is a way
   to ensure that values of interest are available to SystemTap at marked
   points.

3. Sometimes the overhead of a kprobe probepoint is too much (either in
   terms of time or locking) for the particular hotspot we want to probe.


In OLS2006 proceedings, vol. 1
http://www.linuxsymposium.org/2006/linuxsymposium_procv1.pdf

Frank C. Eigler, from SystemTAP, presents its "static probing markers"
(pp. 261-268) in his paper "Problem Solving With Systemtap".

He explains the advantages :

"In exchange for this effort, systemtap marker-based probes are faster and
 more precise than kprobes.  The better precision comes from not having to
 covet the compiler's favours.  Such fickle favours include retaining
 clean boundaries in the instruction stream between interesting statements,
 and precisely describing positions of variables in the stack frame.  Since
 markers don't rely on debugging information, neither favour is required,
 and the compiler can channel its charms into unabated optimization.  The
 speed advantage comes from using direct call instructions rather than int 3
 breakpoints to dispatch to the systemtap handlers.  We will see below just
 how big a difference this makes."

He does a comparison of his "simple" marker solution with kprobes (his simple
solution looks like my generic markers, but with a major race condition).  I
also posted numbers about the markers performance impact a few months ago in
the initial thread.  I can dig into my emails to find them for you if you
consider it important for the Changelog.

He concludes with :

"To the extent that is true, we propose that these groups consider using a
 shared pool of static markers as the basic kernel-side instrumentation
 mechanism.  If they prove to have as low dormant cost and as high active
 performance as initial experience suggests, perhaps this could motivate the
 various tracing efforts and kernel subsystem developers to finally join
 forces.  Let's designate standard trace/probe points once and for all. 
 Tracing backends can attach to these markers the same way systemtap would. 
 There would be no need for them to maintain kernel patches any more. 
 Let's think about it."


This patch:

Add Kconfig menus for the marker code.

[bunk@stusta.de: Never ever select MODULES]
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Acked-by: "Frank Ch. Eigler" <fche@redhat.com>
CC: Christoph Hellwig <hch@infradead.org>
CC: Adrian Bunk <bunk@stusta.de>
---
 kernel/Kconfig.instrumentation |   13 +++++++++++--
 kernel/Makefile                |    1 +
 2 files changed, 12 insertions(+), 2 deletions(-)

Index: linux-2.6-lttng/kernel/Kconfig.instrumentation
===================================================================
--- linux-2.6-lttng.orig/kernel/Kconfig.instrumentation	2007-09-21 14:22:07.000000000 -0400
+++ linux-2.6-lttng/kernel/Kconfig.instrumentation	2007-09-21 14:27:42.000000000 -0400
@@ -3,9 +3,12 @@ menuconfig INSTRUMENTATION
 	default y
 	---help---
 	  Say Y here to get to see options related to performance measurement,
-	  debugging, and testing. This option alone does not add any kernel code.
+	  system-wide debugging, and testing. This option alone does not add any
+	  kernel code.
 
-	  If you say N, all options in this submenu will be skipped and disabled.
+	  If you say N, all options in this submenu will be skipped and
+	  disabled. If you're trying to debug the kernel itself, go see the
+	  Kernel Hacking menu.
 
 if INSTRUMENTATION
 
@@ -37,4 +40,10 @@ config KPROBES
 	  for kernel debugging, non-intrusive instrumentation and testing.
 	  If in doubt, say "N".
 
+config MARKERS
+	bool "Activate markers"
+	help
+	  Place an empty function call at each marker site. Can be
+	  dynamically changed for a probe function.
+
 endif # INSTRUMENTATION
Index: linux-2.6-lttng/kernel/Makefile
===================================================================
--- linux-2.6-lttng.orig/kernel/Makefile	2007-09-21 14:19:51.000000000 -0400
+++ linux-2.6-lttng/kernel/Makefile	2007-09-21 14:28:01.000000000 -0400
@@ -61,6 +61,7 @@ obj-$(CONFIG_SYSCTL) += utsname_sysctl.o
 obj-$(CONFIG_TASK_DELAY_ACCT) += delayacct.o
 obj-$(CONFIG_TASKSTATS) += taskstats.o tsacct.o
 obj-$(CONFIG_RESOURCE_COUNTERS) += res_counter.o
+obj-$(CONFIG_MARKERS) += marker.o
 
 ifneq ($(CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER),y)
 # According to Alan Modra <alan@linuxcare.com.au>, the -fno-omit-frame-pointer is

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

[patch 6/7] Linux Kernel Markers - Documentation

[Mathieu Desnoyers]

[-- Attachment #1: linux-kernel-markers-documentation.patch --]
[-- Type: text/plain, Size: 8989 bytes --]

Here is some documentation explaining what is/how to use the Linux
Kernel Markers.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Acked-by: "Frank Ch. Eigler" <fche@redhat.com>
CC: Christoph Hellwig <hch@infradead.org>
---

 Documentation/markers/markers.txt          |   81 +++++++++++++++++++++++
 Documentation/markers/src/Makefile         |    7 ++
 Documentation/markers/src/marker-example.c |   55 ++++++++++++++++
 Documentation/markers/src/probe-example.c  |   98 +++++++++++++++++++++++++++++
 4 files changed, 241 insertions(+)

Index: linux-2.6-lttng/Documentation/markers/markers.txt
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-lttng/Documentation/markers/markers.txt	2007-09-21 15:07:42.000000000 -0400
@@ -0,0 +1,81 @@
+ 	             Using the Linux Kernel Markers
+
+			    Mathieu Desnoyers
+
+
+This document introduces Linux Kernel Markers and their use. It provides
+examples of how to insert markers in the kernel and connect probe functions to
+them and provides some examples of probe functions.
+
+
+* Purpose of markers
+
+A marker placed in code provides a hook to call a function (probe) that you can
+provide at runtime. A marker can be "on" (a probe is connected to it) or "off"
+(no probe is attached). When a marker is "off" it has no effect, except for
+adding a tiny time penalty (checking a condition for a branch) and space
+penalty (adding a few bytes for the function call at the end of the
+instrumented function and adds a data structure in a separate section).  When a
+marker is "on", the function you provide is called each time the marker is
+executed, in the execution context of the caller. When the function provided
+ends its execution, it returns to the caller (continuing from the marker site).
+
+You can put markers at important locations in the code. Markers are
+lightweight hooks that can pass an arbitrary number of parameters,
+described in a printk-like format string, to the attached probe function.
+
+They can be used for tracing and performance accounting.
+
+
+* Usage
+
+In order to use the macro trace_mark, you should include linux/marker.h.
+
+#include <linux/marker.h>
+
+And,
+
+trace_mark(subsystem_event, "%d %s", someint, somestring);
+Where :
+- subsystem_event is an identifier unique to your event
+    - subsystem is the name of your subsystem.
+    - event is the name of the event to mark.
+- "%d %s" is the formatted string for the serializer.
+- someint is an integer.
+- somestring is a char pointer.
+
+Connecting a function (probe) to a marker is done by providing a probe (function
+to call) for the specific marker through marker_probe_register() and can be
+activated by calling marker_arm(). Marker deactivation can be done by calling
+marker_disarm() as many times as marker_arm() has been called. Removing a probe
+is done through marker_probe_unregister(); it will disarm the probe and make
+sure there is no caller left using the probe when it returns. Probe removal is
+preempt-safe because preemption is disabled around the probe call. See the
+"Probe example" section below for a sample probe module.
+
+The marker mechanism supports inserting multiple instances of the same marker.
+Markers can be put in inline functions, inlined static functions, and
+unrolled loops as well as regular functions.
+
+The naming scheme "subsystem_event" is suggested here as a convention intended
+to limit collisions. Marker names are global to the kernel: they are considered
+as being the same whether they are in the core kernel image or in modules.
+Conflicting format strings for markers with the same name will cause the markers
+to be detected to have a different format string not to be armed and will output
+a printk warning which identifies the inconsistency:
+
+"Format mismatch for probe probe_name (format), marker (format)"
+
+
+* Probe / marker example
+
+See the example provided in Documentation/markers/src
+
+Run, as root :
+
+make
+insmod marker-example.ko (insmod order is not important)
+insmod probe-example.ko
+cat /proc/marker-example (returns an expected error)
+rmmod marker-example probe-example
+dmesg
Index: linux-2.6-lttng/Documentation/markers/src/Makefile
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-lttng/Documentation/markers/src/Makefile	2007-09-21 15:06:17.000000000 -0400
@@ -0,0 +1,7 @@
+obj-m := probe-example.o marker-example.o
+KDIR := /lib/modules/$(shell uname -r)/build
+PWD := $(shell pwd)
+default:
+	$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
+clean:
+	rm -f *.mod.c *.ko *.o
Index: linux-2.6-lttng/Documentation/markers/src/marker-example.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-lttng/Documentation/markers/src/marker-example.c	2007-09-21 15:06:17.000000000 -0400
@@ -0,0 +1,55 @@
+/* marker-example.c
+ *
+ * Executes a marker when /proc/marker-example is opened.
+ *
+ * (C) Copyright 2007 Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
+ *
+ * This file is released under the GPLv2.
+ * See the file COPYING for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/marker.h>
+#include <linux/sched.h>
+#include <linux/proc_fs.h>
+
+struct proc_dir_entry *pentry_example = NULL;
+
+static int my_open(struct inode *inode, struct file *file)
+{
+	int i;
+
+	trace_mark(subsystem_event, "%d %s", 123, "example string");
+	for (i=0; i<10; i++) {
+		trace_mark(subsystem_eventb, MARK_NOARGS);
+	}
+	return -EPERM;
+}
+
+static struct file_operations mark_ops = {
+	.open = my_open,
+};
+
+static int example_init(void)
+{
+	printk(KERN_ALERT "example init\n");
+	pentry_example = create_proc_entry("marker-example", 0444, NULL);
+	if (pentry_example)
+		pentry_example->proc_fops = &mark_ops;
+	else
+		return -EPERM;
+	return 0;
+}
+
+static void example_exit(void)
+{
+	printk(KERN_ALERT "example exit\n");
+	remove_proc_entry("marker-example", NULL);
+}
+
+module_init(example_init)
+module_exit(example_exit)
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Mathieu Desnoyers");
+MODULE_DESCRIPTION("Marker example");
Index: linux-2.6-lttng/Documentation/markers/src/probe-example.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-lttng/Documentation/markers/src/probe-example.c	2007-09-21 15:06:17.000000000 -0400
@@ -0,0 +1,98 @@
+/* probe-example.c
+ *
+ * Connects two functions to marker call sites.
+ *
+ * (C) Copyright 2007 Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
+ *
+ * This file is released under the GPLv2.
+ * See the file COPYING for more details.
+ */
+
+#include <linux/sched.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/marker.h>
+#include <asm/atomic.h>
+
+struct probe_data {
+	const char *name;
+	const char *format;
+	marker_probe_func *probe_func;
+};
+
+void probe_subsystem_event(const struct __mark_marker *mdata,
+		void *private, const char *format, ...)
+{
+	va_list ap;
+	/* Declare args */
+	unsigned int value;
+	const char *mystr;
+
+	/* Assign args */
+	va_start(ap, format);
+	value = va_arg(ap, typeof(value));
+	mystr = va_arg(ap, typeof(mystr));
+
+	/* Call printk */
+	printk("Value %u, string %s\n", value, mystr);
+
+	/* or count, check rights, serialize data in a buffer */
+
+	va_end(ap);
+}
+
+atomic_t eventb_count = ATOMIC_INIT(0);
+
+void probe_subsystem_eventb(const struct __mark_marker *mdata,
+	void *private, const char *format, ...)
+{
+	/* Increment counter */
+	atomic_inc(&eventb_count);
+}
+
+static struct probe_data probe_array[] =
+{
+	{	.name = "subsystem_event",
+		.format = "%d %s",
+		.probe_func = probe_subsystem_event },
+	{	.name = "subsystem_eventb",
+		.format = MARK_NOARGS,
+		.probe_func = probe_subsystem_eventb },
+};
+
+static int __init probe_init(void)
+{
+	int result;
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(probe_array); i++) {
+		result = marker_probe_register(probe_array[i].name,
+				probe_array[i].format,
+				probe_array[i].probe_func, &probe_array[i]);
+		if (result)
+			printk(KERN_INFO "Unable to register probe %s\n",
+				probe_array[i].name);
+		result = marker_arm(probe_array[i].name);
+		if (result)
+			printk(KERN_INFO "Unable to arm probe %s\n",
+				probe_array[i].name);
+	}
+	return 0;
+}
+
+static void __exit probe_fini(void)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(probe_array); i++) {
+		marker_probe_unregister(probe_array[i].name);
+	}
+	printk("Number of event b : %u\n", atomic_read(&eventb_count));
+}
+
+module_init(probe_init);
+module_exit(probe_fini);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Mathieu Desnoyers");
+MODULE_DESCRIPTION("SUBSYSTEM Probe");

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

[patch 7/7] Port of blktrace to the Linux Kernel Markers.

[Mathieu Desnoyers]

[-- Attachment #1: linux-kernel-markers-port-blktrace-to-markers.patch --]
[-- Type: text/plain, Size: 27086 bytes --]

Here is the first stage of a port of blktrace to the Linux Kernel Markers. The
advantage of this port is that it minimizes the impact on the running when
blktrace is not active.

A few remarks : this patch has the positive effect of removing some code
from the block io tracing hot paths, minimizing the i-cache impact in a
system where the io tracing is compiled in but inactive.

It also moves the blk tracing code from a header (and therefore from the
body of the instrumented functions) to a separate C file.

There, as soon as one device has to be traced, all devices have to
execute the tracing function call when they pass by the instrumentation site.
This is slower than the previous inline function which tested the condition
quickly.

It does not make the code smaller, since I left all the specialized
tracing functions for requests, bio, generic, remap, which would go away
once a generic infrastructure is in place to serialize the information
passed to the marker. This is mostly why I consider it as a step towards the
full improvements that could bring the markers.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Acked-by: "Frank Ch. Eigler" <fche@redhat.com>
CC: Jens Axboe <jens.axboe@oracle.com>
---

 block/Kconfig                |    1 
 block/blktrace.c             |  343 ++++++++++++++++++++++++++++++++++++++++++-
 block/elevator.c             |    6 
 block/ll_rw_blk.c            |   35 ++--
 drivers/block/cciss.c        |    4 
 drivers/md/dm.c              |   14 -
 fs/bio.c                     |    6 
 include/linux/blktrace_api.h |  145 +-----------------
 mm/bounce.c                  |    4 
 mm/highmem.c                 |    2 
 10 files changed, 388 insertions(+), 172 deletions(-)

Index: linux-2.6-lttng/block/elevator.c
===================================================================
--- linux-2.6-lttng.orig/block/elevator.c	2007-09-24 10:58:59.000000000 -0400
+++ linux-2.6-lttng/block/elevator.c	2007-09-24 10:59:07.000000000 -0400
@@ -32,7 +32,7 @@
 #include <linux/init.h>
 #include <linux/compiler.h>
 #include <linux/delay.h>
-#include <linux/blktrace_api.h>
+#include <linux/marker.h>
 #include <linux/hash.h>
 
 #include <asm/uaccess.h>
@@ -548,7 +548,7 @@ void elv_insert(struct request_queue *q,
 	unsigned ordseq;
 	int unplug_it = 1;
 
-	blk_add_trace_rq(q, rq, BLK_TA_INSERT);
+	trace_mark(blk_request_insert, "%p %p", q, rq);
 
 	rq->q = q;
 
@@ -735,7 +735,7 @@ struct request *elv_next_request(struct 
 			 * not be passed by new incoming requests
 			 */
 			rq->cmd_flags |= REQ_STARTED;
-			blk_add_trace_rq(q, rq, BLK_TA_ISSUE);
+			trace_mark(blk_request_issue, "%p %p", q, rq);
 		}
 
 		if (!q->boundary_rq || q->boundary_rq == rq) {
Index: linux-2.6-lttng/block/ll_rw_blk.c
===================================================================
--- linux-2.6-lttng.orig/block/ll_rw_blk.c	2007-09-24 10:58:59.000000000 -0400
+++ linux-2.6-lttng/block/ll_rw_blk.c	2007-09-24 10:59:07.000000000 -0400
@@ -28,6 +28,7 @@
 #include <linux/task_io_accounting_ops.h>
 #include <linux/interrupt.h>
 #include <linux/cpu.h>
+#include <linux/marker.h>
 #include <linux/blktrace_api.h>
 #include <linux/fault-inject.h>
 #include <linux/scatterlist.h>
@@ -1593,7 +1594,7 @@ void blk_plug_device(struct request_queu
 
 	if (!test_and_set_bit(QUEUE_FLAG_PLUGGED, &q->queue_flags)) {
 		mod_timer(&q->unplug_timer, jiffies + q->unplug_delay);
-		blk_add_trace_generic(q, NULL, 0, BLK_TA_PLUG);
+		trace_mark(blk_plug_device, "%p %p %d", q, NULL, 0);
 	}
 }
 
@@ -1659,7 +1660,7 @@ static void blk_backing_dev_unplug(struc
 	 * devices don't necessarily have an ->unplug_fn defined
 	 */
 	if (q->unplug_fn) {
-		blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_IO, NULL,
+		trace_mark(blk_pdu_unplug_io, "%p %p %d", q, NULL,
 					q->rq.count[READ] + q->rq.count[WRITE]);
 
 		q->unplug_fn(q);
@@ -1671,7 +1672,7 @@ static void blk_unplug_work(struct work_
 	struct request_queue *q =
 		container_of(work, struct request_queue, unplug_work);
 
-	blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_IO, NULL,
+	trace_mark(blk_pdu_unplug_io, "%p %p %d", q, NULL,
 				q->rq.count[READ] + q->rq.count[WRITE]);
 
 	q->unplug_fn(q);
@@ -1681,7 +1682,7 @@ static void blk_unplug_timeout(unsigned 
 {
 	struct request_queue *q = (struct request_queue *)data;
 
-	blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_TIMER, NULL,
+	trace_mark(blk_pdu_unplug_timer, "%p %p %d", q, NULL,
 				q->rq.count[READ] + q->rq.count[WRITE]);
 
 	kblockd_schedule_work(&q->unplug_work);
@@ -2201,7 +2202,7 @@ rq_starved:
 	
 	rq_init(q, rq);
 
-	blk_add_trace_generic(q, bio, rw, BLK_TA_GETRQ);
+	trace_mark(blk_get_request, "%p %p %d", q, bio, rw);
 out:
 	return rq;
 }
@@ -2231,7 +2232,7 @@ static struct request *get_request_wait(
 		if (!rq) {
 			struct io_context *ioc;
 
-			blk_add_trace_generic(q, bio, rw, BLK_TA_SLEEPRQ);
+			trace_mark(blk_sleep_request, "%p %p %d", q, bio, rw);
 
 			__generic_unplug_device(q);
 			spin_unlock_irq(q->queue_lock);
@@ -2305,7 +2306,7 @@ EXPORT_SYMBOL(blk_start_queueing);
  */
 void blk_requeue_request(struct request_queue *q, struct request *rq)
 {
-	blk_add_trace_rq(q, rq, BLK_TA_REQUEUE);
+	trace_mark(blk_requeue, "%p %p", q, rq);
 
 	if (blk_rq_tagged(rq))
 		blk_queue_end_tag(q, rq);
@@ -3028,7 +3029,7 @@ static int __make_request(struct request
 			if (!ll_back_merge_fn(q, req, bio))
 				break;
 
-			blk_add_trace_bio(q, bio, BLK_TA_BACKMERGE);
+			trace_mark(blk_bio_backmerge, "%p %p", q, bio);
 
 			req->biotail->bi_next = bio;
 			req->biotail = bio;
@@ -3045,7 +3046,7 @@ static int __make_request(struct request
 			if (!ll_front_merge_fn(q, req, bio))
 				break;
 
-			blk_add_trace_bio(q, bio, BLK_TA_FRONTMERGE);
+			trace_mark(blk_bio_frontmerge, "%p %p", q, bio);
 
 			bio->bi_next = req->bio;
 			req->bio = bio;
@@ -3128,9 +3129,10 @@ static inline void blk_partition_remap(s
 		bio->bi_sector += p->start_sect;
 		bio->bi_bdev = bdev->bd_contains;
 
-		blk_add_trace_remap(bdev_get_queue(bio->bi_bdev), bio,
-				    bdev->bd_dev, bio->bi_sector,
-				    bio->bi_sector - p->start_sect);
+		trace_mark(blk_remap, "%p %p %llu %llu %llu",
+				    bdev_get_queue(bio->bi_bdev), bio,
+				    (u64)bdev->bd_dev, (u64)bio->bi_sector,
+				    (u64)bio->bi_sector - p->start_sect);
 	}
 }
 
@@ -3295,10 +3297,11 @@ end_io:
 		blk_partition_remap(bio);
 
 		if (old_sector != -1)
-			blk_add_trace_remap(q, bio, old_dev, bio->bi_sector,
-					    old_sector);
+			trace_mark(blk_remap, "%p %p %llu %llu %llu",
+				q, bio, (u64)old_dev,
+				(u64)bio->bi_sector, (u64)old_sector);
 
-		blk_add_trace_bio(q, bio, BLK_TA_QUEUE);
+		trace_mark(blk_bio_queue, "%p %p", q, bio);
 
 		old_sector = bio->bi_sector;
 		old_dev = bio->bi_bdev->bd_dev;
@@ -3445,7 +3448,7 @@ static int __end_that_request_first(stru
 	int total_bytes, bio_nbytes, error, next_idx = 0;
 	struct bio *bio;
 
-	blk_add_trace_rq(req->q, req, BLK_TA_COMPLETE);
+	trace_mark(blk_request_complete, "%p %p", req->q, req);
 
 	/*
 	 * extend uptodate bool to allow < 0 value to be direct io error
Index: linux-2.6-lttng/block/Kconfig
===================================================================
--- linux-2.6-lttng.orig/block/Kconfig	2007-09-24 10:58:59.000000000 -0400
+++ linux-2.6-lttng/block/Kconfig	2007-09-24 10:59:07.000000000 -0400
@@ -32,6 +32,7 @@ config BLK_DEV_IO_TRACE
 	depends on SYSFS
 	select RELAY
 	select DEBUG_FS
+	select MARKERS
 	help
 	  Say Y here, if you want to be able to trace the block layer actions
 	  on a given queue. Tracing allows you to see any traffic happening
Index: linux-2.6-lttng/block/blktrace.c
===================================================================
--- linux-2.6-lttng.orig/block/blktrace.c	2007-09-24 10:58:59.000000000 -0400
+++ linux-2.6-lttng/block/blktrace.c	2007-09-24 10:59:07.000000000 -0400
@@ -23,11 +23,19 @@
 #include <linux/mutex.h>
 #include <linux/debugfs.h>
 #include <linux/time.h>
+#include <linux/marker.h>
 #include <asm/uaccess.h>
 
 static DEFINE_PER_CPU(unsigned long long, blk_trace_cpu_offset) = { 0, };
 static unsigned int blktrace_seq __read_mostly = 1;
 
+/* Global reference count of probes */
+static DEFINE_MUTEX(blk_probe_mutex);
+static int blk_probes_ref;
+
+int blk_probe_arm(void);
+void blk_probe_disarm(void);
+
 /*
  * Send out a notify message.
  */
@@ -179,7 +187,7 @@ void __blk_add_trace(struct blk_trace *b
 EXPORT_SYMBOL_GPL(__blk_add_trace);
 
 static struct dentry *blk_tree_root;
-static struct mutex blk_tree_mutex;
+static DEFINE_MUTEX(blk_tree_mutex);
 static unsigned int root_users;
 
 static inline void blk_remove_root(void)
@@ -229,6 +237,10 @@ static void blk_trace_cleanup(struct blk
 	blk_remove_tree(bt->dir);
 	free_percpu(bt->sequence);
 	kfree(bt);
+	mutex_lock(&blk_probe_mutex);
+	if (--blk_probes_ref == 0)
+		blk_probe_disarm();
+	mutex_unlock(&blk_probe_mutex);
 }
 
 static int blk_trace_remove(struct request_queue *q)
@@ -386,6 +398,11 @@ static int blk_trace_setup(struct reques
 		goto err;
 	}
 
+	mutex_lock(&blk_probe_mutex);
+	if (!blk_probes_ref++)
+		blk_probe_arm();
+	mutex_unlock(&blk_probe_mutex);
+
 	return 0;
 err:
 	if (dir)
@@ -549,9 +566,331 @@ static void blk_trace_set_ht_offsets(voi
 #endif
 }
 
+/**
+ * blk_add_trace_rq - Add a trace for a request oriented action
+ * Expected variable arguments :
+ * @q:		queue the io is for
+ * @rq:		the source request
+ *
+ * Description:
+ *     Records an action against a request. Will log the bio offset + size.
+ *
+ **/
+static void blk_add_trace_rq(const struct __mark_marker *mdata,
+	void *private_data, const char *fmt, ...)
+{
+	va_list args;
+	u32 what;
+	struct blk_trace *bt;
+	int rw;
+	struct blk_probe_data *pinfo = mdata->pdata;
+	struct request_queue *q;
+	struct request *rq;
+
+	va_start(args, fmt);
+	q = va_arg(args, struct request_queue *);
+	rq = va_arg(args, struct request *);
+	va_end(args);
+
+	what = pinfo->flags;
+	bt = q->blk_trace;
+	rw = rq->cmd_flags & 0x03;
+
+	if (likely(!bt))
+		return;
+
+	if (blk_pc_request(rq)) {
+		what |= BLK_TC_ACT(BLK_TC_PC);
+		__blk_add_trace(bt, 0, rq->data_len, rw, what, rq->errors, sizeof(rq->cmd), rq->cmd);
+	} else  {
+		what |= BLK_TC_ACT(BLK_TC_FS);
+		__blk_add_trace(bt, rq->hard_sector, rq->hard_nr_sectors << 9, rw, what, rq->errors, 0, NULL);
+	}
+}
+
+/**
+ * blk_add_trace_bio - Add a trace for a bio oriented action
+ * Expected variable arguments :
+ * @q:		queue the io is for
+ * @bio:	the source bio
+ *
+ * Description:
+ *     Records an action against a bio. Will log the bio offset + size.
+ *
+ **/
+static void blk_add_trace_bio(const struct __mark_marker *mdata,
+	void *private_data, const char *fmt, ...)
+{
+	va_list args;
+	u32 what;
+	struct blk_trace *bt;
+	struct blk_probe_data *pinfo = mdata->pdata;
+	struct request_queue *q;
+	struct bio *bio;
+
+	va_start(args, fmt);
+	q = va_arg(args, struct request_queue *);
+	bio = va_arg(args, struct bio *);
+	va_end(args);
+
+	what = pinfo->flags;
+	bt = q->blk_trace;
+
+	if (likely(!bt))
+		return;
+
+	__blk_add_trace(bt, bio->bi_sector, bio->bi_size, bio->bi_rw, what, !bio_flagged(bio, BIO_UPTODATE), 0, NULL);
+}
+
+/**
+ * blk_add_trace_generic - Add a trace for a generic action
+ * Expected variable arguments :
+ * @q:		queue the io is for
+ * @bio:	the source bio
+ * @rw:		the data direction
+ *
+ * Description:
+ *     Records a simple trace
+ *
+ **/
+static void blk_add_trace_generic(const struct __mark_marker *mdata,
+	void *private_data, const char *fmt, ...)
+{
+	va_list args;
+	struct blk_trace *bt;
+	u32 what;
+	struct blk_probe_data *pinfo = mdata->pdata;
+	struct request_queue *q;
+	struct bio *bio;
+	int rw;
+
+	va_start(args, fmt);
+	q = va_arg(args, struct request_queue *);
+	bio = va_arg(args, struct bio *);
+	rw = va_arg(args, int);
+	va_end(args);
+
+	what = pinfo->flags;
+	bt = q->blk_trace;
+
+	if (likely(!bt))
+		return;
+
+	if (bio)
+		blk_add_trace_bio(mdata, "%p %p", NULL, q, bio);
+	else
+		__blk_add_trace(bt, 0, 0, rw, what, 0, 0, NULL);
+}
+
+/**
+ * blk_add_trace_pdu_ll - Add a trace for a bio with any integer payload
+ * Expected variable arguments :
+ * @q:		queue the io is for
+ * @bio:	the source bio
+ * @pdu:	the long long integer payload
+ *
+ **/
+static inline void blk_trace_integer(struct request_queue *q, struct bio *bio, unsigned long long pdu,
+					u32 what)
+{
+	struct blk_trace *bt;
+	__be64 rpdu;
+
+	bt = q->blk_trace;
+	rpdu = cpu_to_be64(pdu);
+
+	if (likely(!bt))
+		return;
+
+	if (bio)
+		__blk_add_trace(bt, bio->bi_sector, bio->bi_size, bio->bi_rw, what,
+					!bio_flagged(bio, BIO_UPTODATE), sizeof(rpdu), &rpdu);
+	else
+		__blk_add_trace(bt, 0, 0, 0, what, 0, sizeof(rpdu), &rpdu);
+}
+
+/**
+ * blk_add_trace_pdu_ll - Add a trace for a bio with an long long integer
+ * payload
+ * Expected variable arguments :
+ * @q:		queue the io is for
+ * @bio:	the source bio
+ * @pdu:	the long long integer payload
+ *
+ * Description:
+ *     Adds a trace with some long long integer payload. This might be an unplug
+ *     option given as the action, with the depth at unplug time given as the
+ *     payload
+ *
+ **/
+static void blk_add_trace_pdu_ll(const struct __mark_marker *mdata,
+	void *private_data, const char *fmt, ...)
+{
+	va_list args;
+	struct blk_probe_data *pinfo = mdata->pdata;
+	struct request_queue *q;
+	struct bio *bio;
+	unsigned long long pdu;
+	u32 what;
+
+	what = pinfo->flags;
+
+	va_start(args, fmt);
+	q = va_arg(args, struct request_queue *);
+	bio = va_arg(args, struct bio *);
+	pdu = va_arg(args, unsigned long long);
+	va_end(args);
+
+	blk_trace_integer(q, bio, pdu, what);
+}
+
+
+/**
+ * blk_add_trace_pdu_int - Add a trace for a bio with an integer payload
+ * Expected variable arguments :
+ * @q:		queue the io is for
+ * @bio:	the source bio
+ * @pdu:	the integer payload
+ *
+ * Description:
+ *     Adds a trace with some integer payload. This might be an unplug
+ *     option given as the action, with the depth at unplug time given
+ *     as the payload
+ *
+ **/
+static void blk_add_trace_pdu_int(const struct __mark_marker *mdata,
+	void *private_data, const char *fmt, ...)
+{
+	va_list args;
+	struct blk_probe_data *pinfo = mdata->pdata;
+	struct request_queue *q;
+	struct bio *bio;
+	unsigned int pdu;
+	u32 what;
+
+	what = pinfo->flags;
+
+	va_start(args, fmt);
+	q = va_arg(args, struct request_queue *);
+	bio = va_arg(args, struct bio *);
+	pdu = va_arg(args, unsigned int);
+	va_end(args);
+
+	blk_trace_integer(q, bio, pdu, what);
+}
+
+/**
+ * blk_add_trace_remap - Add a trace for a remap operation
+ * Expected variable arguments :
+ * @q:		queue the io is for
+ * @bio:	the source bio
+ * @dev:	target device
+ * @from:	source sector
+ * @to:		target sector
+ *
+ * Description:
+ *     Device mapper or raid target sometimes need to split a bio because
+ *     it spans a stripe (or similar). Add a trace for that action.
+ *
+ **/
+static void blk_add_trace_remap(const struct __mark_marker *mdata,
+	void *private_data, const char *fmt, ...)
+{
+	va_list args;
+	struct blk_trace *bt;
+	struct blk_io_trace_remap r;
+	u32 what;
+	struct blk_probe_data *pinfo = mdata->pdata;
+	struct request_queue *q;
+	struct bio *bio;
+	u64 dev, from, to;
+
+	va_start(args, fmt);
+	q = va_arg(args, struct request_queue *);
+	bio = va_arg(args, struct bio *);
+	dev = va_arg(args, u64);
+	from = va_arg(args, u64);
+	to = va_arg(args, u64);
+	va_end(args);
+
+	what = pinfo->flags;
+	bt = q->blk_trace;
+
+	if (likely(!bt))
+		return;
+
+	r.device = cpu_to_be32(dev);
+	r.device_from = cpu_to_be32(bio->bi_bdev->bd_dev);
+	r.sector = cpu_to_be64(to);
+
+	__blk_add_trace(bt, from, bio->bi_size, bio->bi_rw, BLK_TA_REMAP, !bio_flagged(bio, BIO_UPTODATE), sizeof(r), &r);
+}
+
+#define FACILITY_NAME "blk"
+
+static struct blk_probe_data probe_array[] =
+{
+	{ "blk_bio_queue", "%p %p", BLK_TA_QUEUE, blk_add_trace_bio },
+	{ "blk_bio_backmerge", "%p %p", BLK_TA_BACKMERGE, blk_add_trace_bio },
+	{ "blk_bio_frontmerge", "%p %p", BLK_TA_FRONTMERGE, blk_add_trace_bio },
+	{ "blk_get_request", "%p %p %d", BLK_TA_GETRQ, blk_add_trace_generic },
+	{ "blk_sleep_request", "%p %p %d", BLK_TA_SLEEPRQ,
+		blk_add_trace_generic },
+	{ "blk_requeue", "%p %p", BLK_TA_REQUEUE, blk_add_trace_rq },
+	{ "blk_request_issue", "%p %p", BLK_TA_ISSUE, blk_add_trace_rq },
+	{ "blk_request_complete", "%p %p", BLK_TA_COMPLETE, blk_add_trace_rq },
+	{ "blk_plug_device", "%p %p %d", BLK_TA_PLUG, blk_add_trace_generic },
+	{ "blk_pdu_unplug_io", "%p %p %d", BLK_TA_UNPLUG_IO,
+		blk_add_trace_pdu_int },
+	{ "blk_pdu_unplug_timer", "%p %p %d", BLK_TA_UNPLUG_TIMER,
+		blk_add_trace_pdu_int },
+	{ "blk_request_insert", "%p %p", BLK_TA_INSERT,
+		blk_add_trace_rq },
+	{ "blk_pdu_split", "%p %p %llu", BLK_TA_SPLIT,
+		blk_add_trace_pdu_ll },
+	{ "blk_bio_bounce", "%p %p", BLK_TA_BOUNCE, blk_add_trace_bio },
+	{ "blk_remap", "%p %p %llu %llu %llu", BLK_TA_REMAP,
+		blk_add_trace_remap },
+};
+
+
+int blk_probe_arm(void)
+{
+	int result;
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(probe_array); i++) {
+		result = marker_probe_register(probe_array[i].name,
+				probe_array[i].format,
+				probe_array[i].callback, &probe_array[i]);
+		if (result)
+			printk(KERN_INFO
+				"blktrace unable to register probe %s\n",
+				probe_array[i].name);
+		result = marker_arm(probe_array[i].name);
+		if (result)
+			printk(KERN_INFO
+				"blktrace unable to arm probe %s\n",
+				probe_array[i].name);
+	}
+	return 0;
+}
+
+void blk_probe_disarm(void)
+{
+	int i, err;
+
+	for (i = 0; i < ARRAY_SIZE(probe_array); i++) {
+		err = marker_disarm(probe_array[i].name);
+		WARN_ON(err);
+		err = IS_ERR(marker_probe_unregister(probe_array[i].name));
+		WARN_ON(err);
+	}
+}
+
+
 static __init int blk_trace_init(void)
 {
-	mutex_init(&blk_tree_mutex);
 	on_each_cpu(blk_trace_check_cpu_time, NULL, 1, 1);
 	blk_trace_set_ht_offsets();
 
Index: linux-2.6-lttng/include/linux/blktrace_api.h
===================================================================
--- linux-2.6-lttng.orig/include/linux/blktrace_api.h	2007-09-24 10:58:59.000000000 -0400
+++ linux-2.6-lttng/include/linux/blktrace_api.h	2007-09-24 10:59:07.000000000 -0400
@@ -3,6 +3,7 @@
 
 #include <linux/blkdev.h>
 #include <linux/relay.h>
+#include <linux/marker.h>
 
 /*
  * Trace categories
@@ -142,150 +143,22 @@ struct blk_user_trace_setup {
 	u32 pid;
 };
 
+/* Probe data used for probe-marker connection */
+struct blk_probe_data {
+	const char *name;
+	const char *format;
+	u32 flags;
+	marker_probe_func *callback;
+};
+
 #if defined(CONFIG_BLK_DEV_IO_TRACE)
 extern int blk_trace_ioctl(struct block_device *, unsigned, char __user *);
 extern void blk_trace_shutdown(struct request_queue *);
 extern void __blk_add_trace(struct blk_trace *, sector_t, int, int, u32, int, int, void *);
 
-/**
- * blk_add_trace_rq - Add a trace for a request oriented action
- * @q:		queue the io is for
- * @rq:		the source request
- * @what:	the action
- *
- * Description:
- *     Records an action against a request. Will log the bio offset + size.
- *
- **/
-static inline void blk_add_trace_rq(struct request_queue *q, struct request *rq,
-				    u32 what)
-{
-	struct blk_trace *bt = q->blk_trace;
-	int rw = rq->cmd_flags & 0x03;
-
-	if (likely(!bt))
-		return;
-
-	if (blk_pc_request(rq)) {
-		what |= BLK_TC_ACT(BLK_TC_PC);
-		__blk_add_trace(bt, 0, rq->data_len, rw, what, rq->errors, sizeof(rq->cmd), rq->cmd);
-	} else  {
-		what |= BLK_TC_ACT(BLK_TC_FS);
-		__blk_add_trace(bt, rq->hard_sector, rq->hard_nr_sectors << 9, rw, what, rq->errors, 0, NULL);
-	}
-}
-
-/**
- * blk_add_trace_bio - Add a trace for a bio oriented action
- * @q:		queue the io is for
- * @bio:	the source bio
- * @what:	the action
- *
- * Description:
- *     Records an action against a bio. Will log the bio offset + size.
- *
- **/
-static inline void blk_add_trace_bio(struct request_queue *q, struct bio *bio,
-				     u32 what)
-{
-	struct blk_trace *bt = q->blk_trace;
-
-	if (likely(!bt))
-		return;
-
-	__blk_add_trace(bt, bio->bi_sector, bio->bi_size, bio->bi_rw, what, !bio_flagged(bio, BIO_UPTODATE), 0, NULL);
-}
-
-/**
- * blk_add_trace_generic - Add a trace for a generic action
- * @q:		queue the io is for
- * @bio:	the source bio
- * @rw:		the data direction
- * @what:	the action
- *
- * Description:
- *     Records a simple trace
- *
- **/
-static inline void blk_add_trace_generic(struct request_queue *q,
-					 struct bio *bio, int rw, u32 what)
-{
-	struct blk_trace *bt = q->blk_trace;
-
-	if (likely(!bt))
-		return;
-
-	if (bio)
-		blk_add_trace_bio(q, bio, what);
-	else
-		__blk_add_trace(bt, 0, 0, rw, what, 0, 0, NULL);
-}
-
-/**
- * blk_add_trace_pdu_int - Add a trace for a bio with an integer payload
- * @q:		queue the io is for
- * @what:	the action
- * @bio:	the source bio
- * @pdu:	the integer payload
- *
- * Description:
- *     Adds a trace with some integer payload. This might be an unplug
- *     option given as the action, with the depth at unplug time given
- *     as the payload
- *
- **/
-static inline void blk_add_trace_pdu_int(struct request_queue *q, u32 what,
-					 struct bio *bio, unsigned int pdu)
-{
-	struct blk_trace *bt = q->blk_trace;
-	__be64 rpdu = cpu_to_be64(pdu);
-
-	if (likely(!bt))
-		return;
-
-	if (bio)
-		__blk_add_trace(bt, bio->bi_sector, bio->bi_size, bio->bi_rw, what, !bio_flagged(bio, BIO_UPTODATE), sizeof(rpdu), &rpdu);
-	else
-		__blk_add_trace(bt, 0, 0, 0, what, 0, sizeof(rpdu), &rpdu);
-}
-
-/**
- * blk_add_trace_remap - Add a trace for a remap operation
- * @q:		queue the io is for
- * @bio:	the source bio
- * @dev:	target device
- * @from:	source sector
- * @to:		target sector
- *
- * Description:
- *     Device mapper or raid target sometimes need to split a bio because
- *     it spans a stripe (or similar). Add a trace for that action.
- *
- **/
-static inline void blk_add_trace_remap(struct request_queue *q, struct bio *bio,
-				       dev_t dev, sector_t from, sector_t to)
-{
-	struct blk_trace *bt = q->blk_trace;
-	struct blk_io_trace_remap r;
-
-	if (likely(!bt))
-		return;
-
-	r.device = cpu_to_be32(dev);
-	r.device_from = cpu_to_be32(bio->bi_bdev->bd_dev);
-	r.sector = cpu_to_be64(to);
-
-	__blk_add_trace(bt, from, bio->bi_size, bio->bi_rw, BLK_TA_REMAP, !bio_flagged(bio, BIO_UPTODATE), sizeof(r), &r);
-}
-
 #else /* !CONFIG_BLK_DEV_IO_TRACE */
 #define blk_trace_ioctl(bdev, cmd, arg)		(-ENOTTY)
 #define blk_trace_shutdown(q)			do { } while (0)
-#define blk_add_trace_rq(q, rq, what)		do { } while (0)
-#define blk_add_trace_bio(q, rq, what)		do { } while (0)
-#define blk_add_trace_generic(q, rq, rw, what)	do { } while (0)
-#define blk_add_trace_pdu_int(q, what, bio, pdu)	do { } while (0)
-#define blk_add_trace_remap(q, bio, dev, f, t)	do {} while (0)
 #endif /* CONFIG_BLK_DEV_IO_TRACE */
 
 #endif
Index: linux-2.6-lttng/mm/bounce.c
===================================================================
--- linux-2.6-lttng.orig/mm/bounce.c	2007-09-24 10:58:59.000000000 -0400
+++ linux-2.6-lttng/mm/bounce.c	2007-09-24 10:59:07.000000000 -0400
@@ -13,7 +13,7 @@
 #include <linux/init.h>
 #include <linux/hash.h>
 #include <linux/highmem.h>
-#include <linux/blktrace_api.h>
+#include <linux/marker.h>
 #include <asm/tlbflush.h>
 
 #define POOL_SIZE	64
@@ -237,7 +237,7 @@ static void __blk_queue_bounce(struct re
 	if (!bio)
 		return;
 
-	blk_add_trace_bio(q, *bio_orig, BLK_TA_BOUNCE);
+	trace_mark(blk_bio_bounce, "%p %p", q, *bio_orig);
 
 	/*
 	 * at least one page was bounced, fill in possible non-highmem
Index: linux-2.6-lttng/mm/highmem.c
===================================================================
--- linux-2.6-lttng.orig/mm/highmem.c	2007-09-24 10:58:59.000000000 -0400
+++ linux-2.6-lttng/mm/highmem.c	2007-09-24 10:59:07.000000000 -0400
@@ -26,7 +26,7 @@
 #include <linux/init.h>
 #include <linux/hash.h>
 #include <linux/highmem.h>
-#include <linux/blktrace_api.h>
+#include <linux/marker.h>
 #include <asm/tlbflush.h>
 
 /*
Index: linux-2.6-lttng/fs/bio.c
===================================================================
--- linux-2.6-lttng.orig/fs/bio.c	2007-09-24 10:58:59.000000000 -0400
+++ linux-2.6-lttng/fs/bio.c	2007-09-24 10:59:07.000000000 -0400
@@ -25,7 +25,7 @@
 #include <linux/module.h>
 #include <linux/mempool.h>
 #include <linux/workqueue.h>
-#include <linux/blktrace_api.h>
+#include <linux/marker.h>
 #include <scsi/sg.h>		/* for struct sg_iovec */
 
 #define BIO_POOL_SIZE 2
@@ -1072,8 +1072,8 @@ struct bio_pair *bio_split(struct bio *b
 	if (!bp)
 		return bp;
 
-	blk_add_trace_pdu_int(bdev_get_queue(bi->bi_bdev), BLK_TA_SPLIT, bi,
-				bi->bi_sector + first_sectors);
+	trace_mark(blk_pdu_split, "%p %p %llu", bdev_get_queue(bi->bi_bdev), bi,
+				(u64)bi->bi_sector + first_sectors);
 
 	BUG_ON(bi->bi_vcnt != 1);
 	BUG_ON(bi->bi_idx != 0);
Index: linux-2.6-lttng/drivers/block/cciss.c
===================================================================
--- linux-2.6-lttng.orig/drivers/block/cciss.c	2007-09-24 10:58:59.000000000 -0400
+++ linux-2.6-lttng/drivers/block/cciss.c	2007-09-24 10:59:07.000000000 -0400
@@ -37,7 +37,7 @@
 #include <linux/hdreg.h>
 #include <linux/spinlock.h>
 #include <linux/compat.h>
-#include <linux/blktrace_api.h>
+#include <linux/marker.h>
 #include <asm/uaccess.h>
 #include <asm/io.h>
 
@@ -2545,7 +2545,7 @@ after_error_processing:
 	}
 	cmd->rq->data_len = 0;
 	cmd->rq->completion_data = cmd;
-	blk_add_trace_rq(cmd->rq->q, cmd->rq, BLK_TA_COMPLETE);
+	trace_mark(blk_request_complete, "%p %p", cmd->rq->q, cmd->rq);
 	blk_complete_request(cmd->rq);
 }
 
Index: linux-2.6-lttng/drivers/md/dm.c
===================================================================
--- linux-2.6-lttng.orig/drivers/md/dm.c	2007-09-24 10:58:59.000000000 -0400
+++ linux-2.6-lttng/drivers/md/dm.c	2007-09-24 10:59:07.000000000 -0400
@@ -19,7 +19,7 @@
 #include <linux/slab.h>
 #include <linux/idr.h>
 #include <linux/hdreg.h>
-#include <linux/blktrace_api.h>
+#include <linux/marker.h>
 #include <linux/smp_lock.h>
 
 #define DM_MSG_PREFIX "core"
@@ -481,8 +481,8 @@ static void dec_pending(struct dm_io *io
 			wake_up(&io->md->wait);
 
 		if (io->error != DM_ENDIO_REQUEUE) {
-			blk_add_trace_bio(io->md->queue, io->bio,
-					  BLK_TA_COMPLETE);
+			trace_mark(blk_request_complete, "%p %p",
+				io->md->queue, io->bio);
 
 			bio_endio(io->bio, io->bio->bi_size, io->error);
 		}
@@ -578,10 +578,10 @@ static void __map_bio(struct dm_target *
 	r = ti->type->map(ti, clone, &tio->info);
 	if (r == DM_MAPIO_REMAPPED) {
 		/* the bio has been remapped so dispatch it */
-
-		blk_add_trace_remap(bdev_get_queue(clone->bi_bdev), clone,
-				    tio->io->bio->bi_bdev->bd_dev,
-				    clone->bi_sector, sector);
+		trace_mark(blk_remap, "%p %p %llu %llu %llu",
+			bdev_get_queue(clone->bi_bdev), clone,
+			(u64)tio->io->bio->bi_bdev->bd_dev, (u64)sector,
+			(u64)clone->bi_sector);
 
 		generic_make_request(clone);
 	} else if (r < 0 || r == DM_MAPIO_REQUEUE) {

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: [patch 1/7] Seq_file add support for sorted list

[Christoph Hellwig]

On Mon, Sep 24, 2007 at 12:49:51PM -0400, Mathieu Desnoyers wrote:
> Add support for sorted list in seq_file. It aims at changing the way
> /proc/modules and kallsyms iterates on the module list to remove a race between
> module unload and module/symbol listing.
> 
> The list is sorted by ascending list_head pointer address.

While I think we really want this patch I don't quite see how it's
related to the markers.  I think patch 1 and 2 stand on their own.

Re: [patch 4/7] Linux Kernel Markers - Architecture Independent Code

[Christoph Hellwig]

On Mon, Sep 24, 2007 at 12:49:54PM -0400, Mathieu Desnoyers wrote:
> +struct __mark_marker {
> +	const char *name;	/* Marker name */
> +	const char *format;	/* Marker format string, describing the
> +				 * variable argument list.
> +				 */
> +	char state;		/* Marker state. */
> +	marker_probe_func *call;/* Probe handler function pointer */
> +	void *pdata;		/* Private probe data */

This is normally called private in the kernel, and keeping this
consistant would be nice.

> +} __attribute__((aligned(8)));

Why do we care about the alignment here?

> +/* To be used for string format validity checking with gcc */
> +static inline void __attribute__ ((format (printf, 1, 2)))
> +	__mark_check_format(const char *fmt, ...) { }

Please put each of the curly braces on a line of it's own, so it's
clear this is an empty inline from the 1000 feet few, as it first
looks like a prototype.  Also aren't __attributes__ normally afer
the function identifier, ala:

static inline void __mark_check_format(const char *fmt, ...)
		__attribute__ ((format (printf, 1, 2)))
{
}

or is this after notation only for prototypes but not actual implementations?
(yeah, gnu C extensions sometimes have syntax that odd)


> +#ifdef CONFIG_MARKERS
> +void module_update_markers(struct module *probe_module, int *refcount)
> +{
> +	struct module *mod;
> +
> +	mutex_lock(&module_mutex);
> +	list_for_each_entry(mod, &modules, list)
> +		if (!mod->taints)
> +			marker_update_probe_range(mod->markers,
> +				mod->markers + mod->num_markers,
> +				probe_module, refcount);
> +	mutex_unlock(&module_mutex);
> +}
> +EXPORT_SYMBOL_GPL(module_update_markers);

Why is this exported?  The markers code is always built into the kernel,
isn't it?

> +EXPORT_SYMBOL_GPL(module_get_iter_markers);

Same here.

> +/*
> + * Add the marker to the marker hash table. Must be called with markers_mutex
> + * held.
> + */
> +static int add_marker(const char *name,
> +	const char *format, marker_probe_func *probe, void *pdata)

static int add_marker(const char *name, const char *format,
		marker_probe_func *probe, void *private)

> +void marker_update_probe_range(
> +	struct __mark_marker *begin,
> +	struct __mark_marker *end,
> +	struct module *probe_module,
> +	int *refcount)

void marker_update_probe_range(struct __mark_marker *begin,
		struct __mark_marker *end, struct module *probe_module,
		int *refcount)

> +EXPORT_SYMBOL_GPL(marker_update_probe_range);

What is this one exported for?

> +/*
> + * Update probes, removing the faulty probes.
> + * Issues a synchronize_sched() when no reference to the module passed
> + * as parameter is found in the probes so the probe module can be
> + * safely unloaded from now on.
> + */
> +static inline void marker_update_probes(struct module *probe_module)

no need to mark this inline, the compiler takes care of that for you
if nessecary.

> +int marker_get_iter_range(struct __mark_marker **marker,
> +	struct __mark_marker *begin,
> +	struct __mark_marker *end)

int marker_get_iter_range(struct __mark_marker **marker,
		struct __mark_marker *begin, struct __mark_marker *end)

> +	int found = 0;
> +
> +	if (!*marker && begin != end) {
> +		found = 1;
> +		*marker = begin;
> +	} else if (*marker >= begin && *marker < end) {
> +		found = 1;
> +		/*
> +		 * *marker is known to be a valid marker from now on.
> +		 */
> +	}
> +	return found;

	if (!*marker && begin != end) {
		*marker = begin;
		return 1;
	}

	if (*marker >= begin && *marker < end)
		return 1;
	return 0;

?


There seem to be a lot of exports and some functions that don't seem
to be used by the obvious marker use-cases like your example, blktrace
or sputrace.  Care to explain why we'd really want them or better cut
them out for this first submission?

Re: [patch 5/7] Linux Kernel Markers - Use instrumentation kconfig menu

[Christoph Hellwig]

Subject and description sounds rather odd for just wiring up Kconfig
and Makefile.  I'd suggest merging this into the previous patch.
In fact given how small markers are it might make sense to put the
documentation into it aswell, it's probably still a lot below 400k.

Re: [patch 6/7] Linux Kernel Markers - Documentation

[Christoph Hellwig]

On Mon, Sep 24, 2007 at 12:49:56PM -0400, Mathieu Desnoyers wrote:
> Here is some documentation explaining what is/how to use the Linux
> Kernel Markers.

As mentioned in the tracing infrastructure thread I don't think
putting code into Documentation is a good idea.  Either of you really
should start a sample/ toplevel directory for this kind of stuff
including a Kconfig menu etc to be able to build these samples as
part of an allmodconfig.

Re: [patch 1/7] Seq_file add support for sorted list

[Mathieu Desnoyers]

* Christoph Hellwig (hch@infradead.org) wrote:
> On Mon, Sep 24, 2007 at 12:49:51PM -0400, Mathieu Desnoyers wrote:
> > Add support for sorted list in seq_file. It aims at changing the way
> > /proc/modules and kallsyms iterates on the module list to remove a race between
> > module unload and module/symbol listing.
> > 
> > The list is sorted by ascending list_head pointer address.
> 
> While I think we really want this patch I don't quite see how it's
> related to the markers.  I think patch 1 and 2 stand on their own.
> 

As they are currently implemented, the markers use the sorted module
list for marker listing, but I can change their implementation so they
do not require this (and make it a subsequent patch instead).

I could do that to diminish the patchset size a little more. However, it
implies using an interface with a known race condition. Could we just
post this as two different patchsets instead ? I really think the sorted
module list would be important to get in and I don't like to use buggy
unfixed lower level functions.

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: [patch 1/7] Seq_file add support for sorted list

[Christoph Hellwig]

On Mon, Sep 24, 2007 at 01:52:52PM -0400, Mathieu Desnoyers wrote:
> As they are currently implemented, the markers use the sorted module
> list for marker listing, but I can change their implementation so they
> do not require this (and make it a subsequent patch instead).
> 
> I could do that to diminish the patchset size a little more. However, it
> implies using an interface with a known race condition. Could we just
> post this as two different patchsets instead ? I really think the sorted
> module list would be important to get in and I don't like to use buggy
> unfixed lower level functions.

Given that we want to fix the the race I think keeping it as-is is
fine.  I didn't realize you depend on the new behaviour.

Re: [patch 6/7] Linux Kernel Markers - Documentation

[Randy Dunlap]

On Mon, 24 Sep 2007 18:50:44 +0100 Christoph Hellwig wrote:

> On Mon, Sep 24, 2007 at 12:49:56PM -0400, Mathieu Desnoyers wrote:
> > Here is some documentation explaining what is/how to use the Linux
> > Kernel Markers.
> 
> As mentioned in the tracing infrastructure thread I don't think
> putting code into Documentation is a good idea.  Either of you really
> should start a sample/ toplevel directory for this kind of stuff
> including a Kconfig menu etc to be able to build these samples as
> part of an allmodconfig.

I don't have a problem with a samples/ directory except (as I have
already pointed out) it means that people will end up having to look
in 2 places for the information that they need, i.e., both in
samples/ and in Documentation/.  So I really don't see a big need
to split the samples and docs.

What's wrong with building sample code in the Documentation/ directory?

---
~Randy
Phaedrus says that Quality is about caring.

Re: [patch 6/7] Linux Kernel Markers - Documentation

[Christoph Hellwig]

On Mon, Sep 24, 2007 at 10:56:32AM -0700, Randy Dunlap wrote:
> I don't have a problem with a samples/ directory except (as I have
> already pointed out) it means that people will end up having to look
> in 2 places for the information that they need, i.e., both in
> samples/ and in Documentation/.  So I really don't see a big need
> to split the samples and docs.
> 
> What's wrong with building sample code in the Documentation/ directory?

It's not really documentation, it's code :)  If you want to build
documentation from the samples use kerneldoc or similar to extrace the
comments.  Having Documentation/ purely for things not affecting the build
make things a whole lot clearer, but if you absolutely insist on it
we can put it under Documentation/ as long as it's fully integrated into
kbuild and will be built as part of allmodconfig, unlike the current
two patches showing code there.

Re: [patch 0/7] Linux Kernel Markers (redux)

[Christoph Hellwig]

On Mon, Sep 24, 2007 at 12:49:50PM -0400, Mathieu Desnoyers wrote:
> Hi Andrew,
> 
> Following Christoph Hellwig's suggestion, aiming at a Linux Kernel Markers
> inclusion for 2.6.24, I made a simplified version of the Linux Kernel Markers.
> There are no more dependencies on any other patchset.
> 
> The modification only involved turning the immediate values into static
> variables and adapting the documentation accordingly. It will have a little more
> data cache impact when disabled than the version based on the immediate values,
> but it is far less complex.
> 
> Since things have not moved much in the markers area recently (most of the
> concerns were about the immediate values), I expect it to be ready for 2.6.24.

I've done a quick review and except for my usual nitpicking it looks
very good to me.  I'll try my sputrace code with this version and will
report on how it works.

I'd really love to see markers in 2.6.24.  The impact to core code of
the actual markers is minimal with some more struct fields in functions
in the module code, although we'll want Mathieu's fix for the modules
list aswell which is a little more invasive.  But I think we want that
one anyway.

I'd say we probably don't want the blktrace conversion that late in the
game, though - but we can queue that once together with the optimizations
from Mathieu's earlier patches in -mm.

Re: [patch 6/7] Linux Kernel Markers - Documentation

[Randy Dunlap]

On Mon, 24 Sep 2007 19:00:41 +0100 Christoph Hellwig wrote:

> On Mon, Sep 24, 2007 at 10:56:32AM -0700, Randy Dunlap wrote:
> > I don't have a problem with a samples/ directory except (as I have
> > already pointed out) it means that people will end up having to look
> > in 2 places for the information that they need, i.e., both in
> > samples/ and in Documentation/.  So I really don't see a big need
> > to split the samples and docs.
> > 
> > What's wrong with building sample code in the Documentation/ directory?
> 
> It's not really documentation, it's code :)  If you want to build
> documentation from the samples use kerneldoc or similar to extrace the
> comments.  Having Documentation/ purely for things not affecting the build
> make things a whole lot clearer, but if you absolutely insist on it
> we can put it under Documentation/ as long as it's fully integrated into
> kbuild and will be built as part of allmodconfig, unlike the current
> two patches showing code there.
> -

Yes, it has to be integrated into the build system, no doubt.

We really need to give Mathieu and David Wilder an answer so that they
can make progress (and I'm willing to help with this).

To do this, here's my test question:
How much of David's "trace code and documentation" patch can be put
into a samples/ directory?

 Documentation/trace/src/Makefile     |    7 +
 Documentation/trace/src/README       |   18 +
 Documentation/trace/src/fork_trace.c |  119 +++++++
 Documentation/trace/trace.txt        |  164 ++++++++++
 include/linux/trace.h                |   99 ++++++
 lib/Kconfig                          |    9 +
 lib/Makefile                         |    2 +
 lib/trace.c                          |  563 +++++++++++++++++++++++++++
+++++++
 8 files changed, 981 insertions(+), 0 deletions(-)


All of the trace/src/ subdirectory?


---
~Randy
Phaedrus says that Quality is about caring.

Re: [patch 4/7] Linux Kernel Markers - Architecture Independent Code

[Robert P. J. Day]

On Mon, 24 Sep 2007, Christoph Hellwig wrote:

> static inline void __mark_check_format(const char *fmt, ...)
> 		__attribute__ ((format (printf, 1, 2)))
> {
> }

the header file compiler-gcc.h defines the shorter macro "__printf".
is it worth encouraging its use, or does it matter?

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

Re: [patch 6/7] Linux Kernel Markers - Documentation

[Christoph Hellwig]

On Mon, Sep 24, 2007 at 11:13:18AM -0700, Randy Dunlap wrote:
>  Documentation/trace/src/Makefile     |    7 +
>  Documentation/trace/src/README       |   18 +
>  Documentation/trace/src/fork_trace.c |  119 +++++++
>  Documentation/trace/trace.txt        |  164 ++++++++++
>  include/linux/trace.h                |   99 ++++++
>  lib/Kconfig                          |    9 +
>  lib/Makefile                         |    2 +
>  lib/trace.c                          |  563 +++++++++++++++++++++++++++
> +++++++
>  8 files changed, 981 insertions(+), 0 deletions(-)
> 
> 
> All of the trace/src/ subdirectory?

Yes, but only as a single file.  We don't really want READMES in source
directories.  Instead these 18 lines would do a perfect comment on the
top of the file.

Re: [patch 4/7] Linux Kernel Markers - Architecture Independent Code

[Christoph Hellwig]

On Mon, Sep 24, 2007 at 02:15:12PM -0400, Robert P. J. Day wrote:
> On Mon, 24 Sep 2007, Christoph Hellwig wrote:
> 
> > static inline void __mark_check_format(const char *fmt, ...)
> > 		__attribute__ ((format (printf, 1, 2)))
> > {
> > }
> 
> the header file compiler-gcc.h defines the shorter macro "__printf".
> is it worth encouraging its use, or does it matter?

Yes, that's even better.

Re: [patch 4/7] Linux Kernel Markers - Architecture Independent Code

[Mathieu Desnoyers]

* Christoph Hellwig (hch@infradead.org) wrote:
> On Mon, Sep 24, 2007 at 02:15:12PM -0400, Robert P. J. Day wrote:
> > On Mon, 24 Sep 2007, Christoph Hellwig wrote:
> > 
> > > static inline void __mark_check_format(const char *fmt, ...)
> > > 		__attribute__ ((format (printf, 1, 2)))
> > > {
> > > }
> > 
> > the header file compiler-gcc.h defines the shorter macro "__printf".
> > is it worth encouraging its use, or does it matter?
> 
> Yes, that's even better.

Ok, fixing.

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: [patch 6/7] Linux Kernel Markers - Documentation

[Randy Dunlap]

Christoph Hellwig wrote:
> On Mon, Sep 24, 2007 at 11:13:18AM -0700, Randy Dunlap wrote:
>>  Documentation/trace/src/Makefile     |    7 +
>>  Documentation/trace/src/README       |   18 +
>>  Documentation/trace/src/fork_trace.c |  119 +++++++
>>  Documentation/trace/trace.txt        |  164 ++++++++++
>>  include/linux/trace.h                |   99 ++++++
>>  lib/Kconfig                          |    9 +
>>  lib/Makefile                         |    2 +
>>  lib/trace.c                          |  563 +++++++++++++++++++++++++++
>> +++++++
>>  8 files changed, 981 insertions(+), 0 deletions(-)
>>
>>
>> All of the trace/src/ subdirectory?
> 
> Yes, but only as a single file.  We don't really want READMES in source
> directories.  Instead these 18 lines would do a perfect comment on the
> top of the file.

That might be OK for this case, but sometimes it makes sense to have
README etc. about how to use the software.  So you would want this
in the Documentation/ tree?  That makes it harder on users.

-- 
~Randy
Phaedrus says that Quality is about caring.

Re: [patch 6/7] Linux Kernel Markers - Documentation

[Christoph Hellwig]

On Mon, Sep 24, 2007 at 11:23:35AM -0700, Randy Dunlap wrote:
> That might be OK for this case, but sometimes it makes sense to have
> README etc. about how to use the software.  So you would want this
> in the Documentation/ tree?  That makes it harder on users.

If it's so complex that we can't describe it in a few dozens lines
it shouldn't be anywhere but the place it belongs and better have a
real use and not just be a sample.  And in the trace case I must
admit that I'd prefer a real use like some simple syscall-trace
over this hack anyway..

Re: [patch 4/7] Linux Kernel Markers - Architecture Independent Code

[Mathieu Desnoyers]

* Christoph Hellwig (hch@infradead.org) wrote:
> On Mon, Sep 24, 2007 at 12:49:54PM -0400, Mathieu Desnoyers wrote:
> > +struct __mark_marker {
> > +	const char *name;	/* Marker name */
> > +	const char *format;	/* Marker format string, describing the
> > +				 * variable argument list.
> > +				 */
> > +	char state;		/* Marker state. */
> > +	marker_probe_func *call;/* Probe handler function pointer */
> > +	void *pdata;		/* Private probe data */
> 
> This is normally called private in the kernel, and keeping this
> consistant would be nice.
> 

Ok, fixing.

> > +} __attribute__((aligned(8)));
> 
> Why do we care about the alignment here?
> 

Because we want to be really-really-really sure GCC won't align this
structure on 32 bytes. Here is the problematic scenario:

Developer A adds a few fields to struct __mark_marker, making it 32
bytes in size.
include/asm-generic/vmlinux.lds.h specifies 

        . = ALIGN(8);                                                   \
        VMLINUX_SYMBOL(__start___markers) = .;                          \
        *(__markers)                                                    \
        VMLINUX_SYMBOL(__stop___markers) = .;

Therefore, the __start___markers "begin" iterator will always be 8 bytes
aligned, but if GCC decides to align the structures on 32 bytes, we can
end up with padding at the beginning of our iterator.

Therefore, to make sure there won't be any unforeseen side-effect of any
changes to this structure, I specify the structure alignment there.

> > +/* To be used for string format validity checking with gcc */
> > +static inline void __attribute__ ((format (printf, 1, 2)))
> > +	__mark_check_format(const char *fmt, ...) { }
> 
> Please put each of the curly braces on a line of it's own, so it's
> clear this is an empty inline from the 1000 feet few, as it first
> looks like a prototype.  Also aren't __attributes__ normally afer
> the function identifier, ala:
> 

Ok, fixing __mark_empty_function too for the braces.

> static inline void __mark_check_format(const char *fmt, ...)
> 		__attribute__ ((format (printf, 1, 2)))
> {
> }
> 
> or is this after notation only for prototypes but not actual implementations?
> (yeah, gnu C extensions sometimes have syntax that odd)
> 

Build error 

In file included from include/linux/module.h:19,
                 from include/linux/crypto.h:22,
                 from arch/i386/kernel/asm-offsets.c:8:
include/linux/marker.h:106: error: expected ',' or ';' before '{' token
distcc[3903] ERROR: compile arch/i386/kernel/asm-offsets.c on dijkstra failed

gcc doesn't like it if I put the attribute after the function in the
implementation. Should I leave it before or separate the prototype from
the implementation ?
> 
> > +#ifdef CONFIG_MARKERS
> > +void module_update_markers(struct module *probe_module, int *refcount)
> > +{
> > +	struct module *mod;
> > +
> > +	mutex_lock(&module_mutex);
> > +	list_for_each_entry(mod, &modules, list)
> > +		if (!mod->taints)
> > +			marker_update_probe_range(mod->markers,
> > +				mod->markers + mod->num_markers,
> > +				probe_module, refcount);
> > +	mutex_unlock(&module_mutex);
> > +}
> > +EXPORT_SYMBOL_GPL(module_update_markers);
> 
> Why is this exported?  The markers code is always built into the kernel,
> isn't it?
> 
> > +EXPORT_SYMBOL_GPL(module_get_iter_markers);
> 
> Same here.

Yep, good point. Fixing.

> > +void marker_update_probe_range(
> > +	struct __mark_marker *begin,
> > +	struct __mark_marker *end,
> > +	struct module *probe_module,
> > +	int *refcount)
> 
> void marker_update_probe_range(struct __mark_marker *begin,
> 		struct __mark_marker *end, struct module *probe_module,
> 		int *refcount)
> 

ok

> > +EXPORT_SYMBOL_GPL(marker_update_probe_range);
> 
> What is this one exported for?
> 

Only used by module.c, should not be exported.

> > +/*
> > + * Update probes, removing the faulty probes.
> > + * Issues a synchronize_sched() when no reference to the module passed
> > + * as parameter is found in the probes so the probe module can be
> > + * safely unloaded from now on.
> > + */
> > +static inline void marker_update_probes(struct module *probe_module)
> 
> no need to mark this inline, the compiler takes care of that for you
> if nessecary.
> 

I'll change all static inlines into static in kernel/marker.c
since, as you point out, gcc knows its job. I originally used all
"static inline" following a comment from Andrew.

> > +	int found = 0;
> > +
> > +	if (!*marker && begin != end) {
> > +		found = 1;
> > +		*marker = begin;
> > +	} else if (*marker >= begin && *marker < end) {
> > +		found = 1;
> > +		/*
> > +		 * *marker is known to be a valid marker from now on.
> > +		 */
> > +	}
> > +	return found;
> 
> 	if (!*marker && begin != end) {
> 		*marker = begin;
> 		return 1;
> 	}
> 
> 	if (*marker >= begin && *marker < end)
> 		return 1;
> 	return 0;
> 
> ?
> 

Clearly, this simple layout did not come out from the evolution of the
code. Will fix.

> 
> There seem to be a lot of exports and some functions that don't seem
> to be used by the obvious marker use-cases like your example, blktrace
> or sputrace.  Care to explain why we'd really want them or better cut
> them out for this first submission?

If you are referring to the exports you just told about in this email,
I'll remove them, they are not needed. As for the "marker_get_iter" and
friends, they are used to list the markers (I provide a /proc interface
to list the markers in the subsequent modules and also use it to dump
the marker list in a trace channel at trace start so I can later
understand the event data by using the format strings as type
identifiers).

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: [patch 5/7] Linux Kernel Markers - Use instrumentation kconfig menu

[Mathieu Desnoyers]

* Christoph Hellwig (hch@infradead.org) wrote:
> Subject and description sounds rather odd for just wiring up Kconfig
> and Makefile.  I'd suggest merging this into the previous patch.
> In fact given how small markers are it might make sense to put the
> documentation into it aswell, it's probably still a lot below 400k.
> 

Good point, let's do it.

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: [patch 4/7] Linux Kernel Markers - Architecture Independent Code

[Christoph Hellwig]

On Mon, Sep 24, 2007 at 02:43:09PM -0400, Mathieu Desnoyers wrote:
> gcc doesn't like it if I put the attribute after the function in the
> implementation. Should I leave it before or separate the prototype from
> the implementation ?

Just keep it where it was.

> > There seem to be a lot of exports and some functions that don't seem
> > to be used by the obvious marker use-cases like your example, blktrace
> > or sputrace.  Care to explain why we'd really want them or better cut
> > them out for this first submission?
> 
> If you are referring to the exports you just told about in this email,
> I'll remove them, they are not needed. As for the "marker_get_iter" and
> friends, they are used to list the markers (I provide a /proc interface
> to list the markers in the subsequent modules and also use it to dump
> the marker list in a trace channel at trace start so I can later
> understand the event data by using the format strings as type
> identifiers).

Sounds conceptually fine, but can we introduce this together with
the actualy users?

Re: [patch 6/7] Linux Kernel Markers - Documentation

[Randy Dunlap]

Christoph Hellwig wrote:
> On Mon, Sep 24, 2007 at 11:23:35AM -0700, Randy Dunlap wrote:
>> That might be OK for this case, but sometimes it makes sense to have
>> README etc. about how to use the software.  So you would want this
>> in the Documentation/ tree?  That makes it harder on users.
> 
> If it's so complex that we can't describe it in a few dozens lines
> it shouldn't be anywhere but the place it belongs and better have a
> real use and not just be a sample.  And in the trace case I must
> admit that I'd prefer a real use like some simple syscall-trace
> over this hack anyway..

I think that samples are perfectly fine for documentation and
that the trace example is a good example.  I think that most people
who need something like that would need to customize it for their
specific needs anyway.

We don't seem to be making progress...


-- 
~Randy
Phaedrus says that Quality is about caring.

Re: [patch 4/7] Linux Kernel Markers - Architecture Independent Code

[Mathieu Desnoyers]

* Christoph Hellwig (hch@infradead.org) wrote:
> On Mon, Sep 24, 2007 at 02:43:09PM -0400, Mathieu Desnoyers wrote:
> > gcc doesn't like it if I put the attribute after the function in the
> > implementation. Should I leave it before or separate the prototype from
> > the implementation ?
> 
> Just keep it where it was.
> 
> > > There seem to be a lot of exports and some functions that don't seem
> > > to be used by the obvious marker use-cases like your example, blktrace
> > > or sputrace.  Care to explain why we'd really want them or better cut
> > > them out for this first submission?
> > 
> > If you are referring to the exports you just told about in this email,
> > I'll remove them, they are not needed. As for the "marker_get_iter" and
> > friends, they are used to list the markers (I provide a /proc interface
> > to list the markers in the subsequent modules and also use it to dump
> > the marker list in a trace channel at trace start so I can later
> > understand the event data by using the format strings as type
> > identifiers).
> 
> Sounds conceptually fine, but can we introduce this together with
> the actualy users?

Sure, I'll move that down in my patch queue.

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: [patch 6/7] Linux Kernel Markers - Documentation

[Christoph Hellwig]

On Mon, Sep 24, 2007 at 11:49:15AM -0700, Randy Dunlap wrote:
> I think that samples are perfectly fine for documentation and
> that the trace example is a good example.  I think that most people
> who need something like that would need to customize it for their
> specific needs anyway.
> 
> We don't seem to be making progress...

Time to bring in a Tie-Breaker :)

Re: [patch 6/7] Linux Kernel Markers - Documentation

[Randy Dunlap]

Christoph Hellwig wrote:
> On Mon, Sep 24, 2007 at 11:49:15AM -0700, Randy Dunlap wrote:
>> I think that samples are perfectly fine for documentation and
>> that the trace example is a good example.  I think that most people
>> who need something like that would need to customize it for their
>> specific needs anyway.
>>
>> We don't seem to be making progress...
> 
> Time to bring in a Tie-Breaker :)

Yes.  Is anyone else interested?   :(


-- 
~Randy
Phaedrus says that Quality is about caring.

Re: [patch 0/7] Linux Kernel Markers (redux)

[Mathieu Desnoyers]

* Christoph Hellwig (hch@infradead.org) wrote:
> On Mon, Sep 24, 2007 at 12:49:50PM -0400, Mathieu Desnoyers wrote:
> > Hi Andrew,
> > 
> > Following Christoph Hellwig's suggestion, aiming at a Linux Kernel Markers
> > inclusion for 2.6.24, I made a simplified version of the Linux Kernel Markers.
> > There are no more dependencies on any other patchset.
> > 
> > The modification only involved turning the immediate values into static
> > variables and adapting the documentation accordingly. It will have a little more
> > data cache impact when disabled than the version based on the immediate values,
> > but it is far less complex.
> > 
> > Since things have not moved much in the markers area recently (most of the
> > concerns were about the immediate values), I expect it to be ready for 2.6.24.
> 
> I've done a quick review and except for my usual nitpicking it looks
> very good to me.  I'll try my sputrace code with this version and will
> report on how it works.
> 
> I'd really love to see markers in 2.6.24.  The impact to core code of
> the actual markers is minimal with some more struct fields in functions
> in the module code, although we'll want Mathieu's fix for the modules
> list aswell which is a little more invasive.  But I think we want that
> one anyway.
> 

Well, since I just moved the marker iterators down in my patchset, I can
move down the module list fix altogether and keep it for later. It will
make the patchset as unintrusive as possible.

> I'd say we probably don't want the blktrace conversion that late in the
> game, though - but we can queue that once together with the optimizations
> from Mathieu's earlier patches in -mm.
> 

I provided blktrace as a first user of the markers, but I agree that it
may be a little late for merging. I can keep it for later too.

Mathieu


-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: [patch 0/7] Linux Kernel Markers (redux)

[Christoph Hellwig]

On Mon, Sep 24, 2007 at 03:04:52PM -0400, Mathieu Desnoyers wrote:
> I provided blktrace as a first user of the markers, but I agree that it
> may be a little late for merging. I can keep it for later too.

I we manage to get Dave's trace patches and your markers in I'll make
sure to get a sputrace version using them in as a demo for both.

Re: [patch 6/7] Linux Kernel Markers - Documentation

[Mathieu Desnoyers]

* Christoph Hellwig (hch@infradead.org) wrote:
> On Mon, Sep 24, 2007 at 12:49:56PM -0400, Mathieu Desnoyers wrote:
> > Here is some documentation explaining what is/how to use the Linux
> > Kernel Markers.
> 
> As mentioned in the tracing infrastructure thread I don't think
> putting code into Documentation is a good idea.  Either of you really
> should start a sample/ toplevel directory for this kind of stuff
> including a Kconfig menu etc to be able to build these samples as
> part of an allmodconfig.
> 

One should have a look at Documentation/kprobes.txt for that kind of
example code / documentation mix.

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: [patch 0/7] Linux Kernel Markers (redux)

[Mathieu Desnoyers]

* Christoph Hellwig (hch@infradead.org) wrote:
> On Mon, Sep 24, 2007 at 03:04:52PM -0400, Mathieu Desnoyers wrote:
> > I provided blktrace as a first user of the markers, but I agree that it
> > may be a little late for merging. I can keep it for later too.
> 
> I we manage to get Dave's trace patches and your markers in I'll make
> sure to get a sputrace version using them in as a demo for both.
> 

Great!

So the state of the patches for next post:

kconfig-instrumentation.patch
linux-kernel-markers.patch

(yeah, only 2 patches!) :)

I'm only waiting for you guys to settle about documentation/samples
before I can repost.

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: [patch 6/7] Linux Kernel Markers - Documentation

[Christoph Hellwig]

On Mon, Sep 24, 2007 at 03:18:11PM -0400, Mathieu Desnoyers wrote:
> > putting code into Documentation is a good idea.  Either of you really
> > should start a sample/ toplevel directory for this kind of stuff
> > including a Kconfig menu etc to be able to build these samples as
> > part of an allmodconfig.
> > 
> 
> One should have a look at Documentation/kprobes.txt for that kind of
> example code / documentation mix.

That one is particularly bad.  It's high on my todo list of things to fix.

Re: [patch 6/7] Linux Kernel Markers - Documentation

[Randy Dunlap]

On Mon, 24 Sep 2007 20:25:04 +0100 Christoph Hellwig wrote:

> On Mon, Sep 24, 2007 at 03:18:11PM -0400, Mathieu Desnoyers wrote:
> > > putting code into Documentation is a good idea.  Either of you really
> > > should start a sample/ toplevel directory for this kind of stuff
> > > including a Kconfig menu etc to be able to build these samples as
> > > part of an allmodconfig.
> > > 
> > 
> > One should have a look at Documentation/kprobes.txt for that kind of
> > example code / documentation mix.
> 
> That one is particularly bad.  It's high on my todo list of things to fix.
> -

I already have it split and building.   Just need to know
where to put it.  :)


---
~Randy
Phaedrus says that Quality is about caring.

Re: [patch 6/7] Linux Kernel Markers - Documentation

[Randy Dunlap]

On Mon, 24 Sep 2007 11:56:35 -0700 Randy Dunlap wrote:

> Christoph Hellwig wrote:
> > On Mon, Sep 24, 2007 at 11:49:15AM -0700, Randy Dunlap wrote:
> >> I think that samples are perfectly fine for documentation and
> >> that the trace example is a good example.  I think that most people
> >> who need something like that would need to customize it for their
> >> specific needs anyway.
> >>
> >> We don't seem to be making progress...
> > 
> > Time to bring in a Tie-Breaker :)
> 
> Yes.  Is anyone else interested?   :(


I guess that's everyone (except those who are sleeping).

Let's not hold up progress.  Just use samples/ for code.

---
~Randy
Phaedrus says that Quality is about caring.

Re: [patch 6/7] Linux Kernel Markers - Documentation

[Mathieu Desnoyers]

* Randy Dunlap (randy.dunlap@oracle.com) wrote:
> On Mon, 24 Sep 2007 11:56:35 -0700 Randy Dunlap wrote:
> 
> > Christoph Hellwig wrote:
> > > On Mon, Sep 24, 2007 at 11:49:15AM -0700, Randy Dunlap wrote:
> > >> I think that samples are perfectly fine for documentation and
> > >> that the trace example is a good example.  I think that most people
> > >> who need something like that would need to customize it for their
> > >> specific needs anyway.
> > >>
> > >> We don't seem to be making progress...
> > > 
> > > Time to bring in a Tie-Breaker :)
> > 
> > Yes.  Is anyone else interested?   :(
> 
> 
> I guess that's everyone (except those who are sleeping).
> 
> Let's not hold up progress.  Just use samples/ for code.

Would you already have the 

Makefile
samples/Kconfig
samples/Makefile

core code handy per chance ? (and probably Kconfig sourcing in every
arch ?)

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: [patch 6/7] Linux Kernel Markers - Documentation

[Randy Dunlap]

On Mon, 24 Sep 2007 17:08:30 -0400 Mathieu Desnoyers wrote:

> * Randy Dunlap (randy.dunlap@oracle.com) wrote:
> > On Mon, 24 Sep 2007 11:56:35 -0700 Randy Dunlap wrote:
> > 
> > > Christoph Hellwig wrote:
> > > > On Mon, Sep 24, 2007 at 11:49:15AM -0700, Randy Dunlap wrote:
> > > >> I think that samples are perfectly fine for documentation and
> > > >> that the trace example is a good example.  I think that most people
> > > >> who need something like that would need to customize it for their
> > > >> specific needs anyway.
> > > >>
> > > >> We don't seem to be making progress...
> > > > 
> > > > Time to bring in a Tie-Breaker :)
> > > 
> > > Yes.  Is anyone else interested?   :(
> > 
> > 
> > I guess that's everyone (except those who are sleeping).
> > 
> > Let's not hold up progress.  Just use samples/ for code.
> 
> Would you already have the 
> 
> Makefile
> samples/Kconfig
> samples/Makefile
> 
> core code handy per chance ? (and probably Kconfig sourcing in every
> arch ?)

Yes.  Here it is.  I'm working on add kprobes to it, but you
can go ahead with markers also.



From: Randy Dunlap <randy.dunlap@oracle.com>

Begin infrastructure for kernel code samples in the samples/ directory.
Add its Kconfig and Kbuild files.
Source its Kconfig file in all arch/ Kconfigs.


Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
 Makefile               |   10 +++++++---
 arch/alpha/Kconfig     |    2 ++
 arch/arm/Kconfig       |    2 ++
 arch/avr32/Kconfig     |    2 ++
 arch/blackfin/Kconfig  |    2 ++
 arch/cris/Kconfig      |    2 ++
 arch/frv/Kconfig       |    2 ++
 arch/h8300/Kconfig     |    2 ++
 arch/i386/Kconfig      |    2 ++
 arch/ia64/Kconfig      |    2 ++
 arch/m32r/Kconfig      |    2 ++
 arch/m68k/Kconfig      |    2 ++
 arch/m68knommu/Kconfig |    2 ++
 arch/mips/Kconfig      |    2 ++
 arch/parisc/Kconfig    |    2 ++
 arch/powerpc/Kconfig   |    2 ++
 arch/ppc/Kconfig       |    2 ++
 arch/s390/Kconfig      |    2 ++
 arch/sh/Kconfig        |    2 ++
 arch/sh64/Kconfig      |    2 ++
 arch/sparc/Kconfig     |    2 ++
 arch/sparc64/Kconfig   |    2 ++
 arch/um/Kconfig        |    2 ++
 arch/v850/Kconfig      |    2 ++
 arch/x86_64/Kconfig    |    2 ++
 arch/xtensa/Kconfig    |    3 ++-
 samples/Kbuild         |    2 ++
 samples/Kconfig        |   11 +++++++++++
 28 files changed, 70 insertions(+), 4 deletions(-)

--- linux-2.6.23-rc7.orig/Makefile
+++ linux-2.6.23-rc7/Makefile
@@ -436,6 +436,7 @@ drivers-y	:= drivers/ sound/
 net-y		:= net/
 libs-y		:= lib/
 core-y		:= usr/
+samples-y	:= samples/
 endif # KBUILD_EXTMOD
 
 ifeq ($(dot-config),1)
@@ -564,10 +565,12 @@ core-y		+= kernel/ mm/ fs/ ipc/ security
 
 vmlinux-dirs	:= $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \
 		     $(core-y) $(core-m) $(drivers-y) $(drivers-m) \
-		     $(net-y) $(net-m) $(libs-y) $(libs-m)))
+		     $(net-y) $(net-m) $(libs-y) $(libs-m))	\
+		     $(samples-y) $(samples-m))
+
 
 vmlinux-alldirs	:= $(sort $(vmlinux-dirs) $(patsubst %/,%,$(filter %/, \
-		     $(init-n) $(init-) \
+		     $(init-n) $(init-) $(samples-n) $(samples-) \
 		     $(core-n) $(core-) $(drivers-n) $(drivers-) \
 		     $(net-n)  $(net-)  $(libs-n)    $(libs-))))
 
@@ -578,6 +581,7 @@ net-y		:= $(patsubst %/, %/built-in.o, $
 libs-y1		:= $(patsubst %/, %/lib.a, $(libs-y))
 libs-y2		:= $(patsubst %/, %/built-in.o, $(libs-y))
 libs-y		:= $(libs-y1) $(libs-y2)
+samples-y	:= $(patsubst %/, %/built-in.o, $(samples-y))
 
 # Build vmlinux
 # ---------------------------------------------------------------------------
@@ -607,7 +611,7 @@ libs-y		:= $(libs-y1) $(libs-y2)
 # System.map is generated to document addresses of all kernel symbols
 
 vmlinux-init := $(head-y) $(init-y)
-vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y)
+vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y) $(samples-y)
 vmlinux-all  := $(vmlinux-init) $(vmlinux-main)
 vmlinux-lds  := arch/$(ARCH)/kernel/vmlinux.lds
 export KBUILD_VMLINUX_OBJS := $(vmlinux-all)
--- /dev/null
+++ linux-2.6.23-rc7/samples/Kbuild
@@ -0,0 +1,2 @@
+# Makefile for Linux samples code
+
--- /dev/null
+++ linux-2.6.23-rc7/samples/Kconfig
@@ -0,0 +1,11 @@
+# samples/Kconfig
+
+menuconfig SAMPLES
+	bool "Sample kernel code"
+	help
+	  You can build and test sample kernel code here.
+
+if SAMPLES
+
+
+endif # SAMPLES
--- linux-2.6.23-rc7.orig/arch/alpha/Kconfig
+++ linux-2.6.23-rc7/arch/alpha/Kconfig
@@ -669,5 +669,7 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+source "samples/Kconfig"
+
 source "lib/Kconfig"
 
--- linux-2.6.23-rc7.orig/arch/arm/Kconfig
+++ linux-2.6.23-rc7/arch/arm/Kconfig
@@ -1067,4 +1067,6 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+source "samples/Kconfig"
+
 source "lib/Kconfig"
--- linux-2.6.23-rc7.orig/arch/avr32/Kconfig
+++ linux-2.6.23-rc7/arch/avr32/Kconfig
@@ -237,4 +237,6 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+source "samples/Kconfig"
+
 source "lib/Kconfig"
--- linux-2.6.23-rc7.orig/arch/blackfin/Kconfig
+++ linux-2.6.23-rc7/arch/blackfin/Kconfig
@@ -1012,4 +1012,6 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+source "samples/Kconfig"
+
 source "lib/Kconfig"
--- linux-2.6.23-rc7.orig/arch/cris/Kconfig
+++ linux-2.6.23-rc7/arch/cris/Kconfig
@@ -202,4 +202,6 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+source "samples/Kconfig"
+
 source "lib/Kconfig"
--- linux-2.6.23-rc7.orig/arch/frv/Kconfig
+++ linux-2.6.23-rc7/arch/frv/Kconfig
@@ -381,4 +381,6 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+source "samples/Kconfig"
+
 source "lib/Kconfig"
--- linux-2.6.23-rc7.orig/arch/h8300/Kconfig
+++ linux-2.6.23-rc7/arch/h8300/Kconfig
@@ -229,4 +229,6 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+source "samples/Kconfig"
+
 source "lib/Kconfig"
--- linux-2.6.23-rc7.orig/arch/i386/Kconfig
+++ linux-2.6.23-rc7/arch/i386/Kconfig
@@ -1260,6 +1260,8 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+source "samples/Kconfig"
+
 source "lib/Kconfig"
 
 #
--- linux-2.6.23-rc7.orig/arch/ia64/Kconfig
+++ linux-2.6.23-rc7/arch/ia64/Kconfig
@@ -594,3 +594,5 @@ source "arch/ia64/Kconfig.debug"
 source "security/Kconfig"
 
 source "crypto/Kconfig"
+
+source "samples/Kconfig"
--- linux-2.6.23-rc7.orig/arch/m32r/Kconfig
+++ linux-2.6.23-rc7/arch/m32r/Kconfig
@@ -434,4 +434,6 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+source "samples/Kconfig"
+
 source "lib/Kconfig"
--- linux-2.6.23-rc7.orig/arch/m68k/Kconfig
+++ linux-2.6.23-rc7/arch/m68k/Kconfig
@@ -689,4 +689,6 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+source "samples/Kconfig"
+
 source "lib/Kconfig"
--- linux-2.6.23-rc7.orig/arch/m68knommu/Kconfig
+++ linux-2.6.23-rc7/arch/m68knommu/Kconfig
@@ -702,4 +702,6 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+source "samples/Kconfig"
+
 source "lib/Kconfig"
--- linux-2.6.23-rc7.orig/arch/mips/Kconfig
+++ linux-2.6.23-rc7/arch/mips/Kconfig
@@ -1924,4 +1924,6 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+source "samples/Kconfig"
+
 source "lib/Kconfig"
--- linux-2.6.23-rc7.orig/arch/parisc/Kconfig
+++ linux-2.6.23-rc7/arch/parisc/Kconfig
@@ -275,4 +275,6 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+source "samples/Kconfig"
+
 source "lib/Kconfig"
--- linux-2.6.23-rc7.orig/arch/powerpc/Kconfig
+++ linux-2.6.23-rc7/arch/powerpc/Kconfig
@@ -662,3 +662,5 @@ config KEYS_COMPAT
 	default y
 
 source "crypto/Kconfig"
+
+source "samples/Kconfig"
--- linux-2.6.23-rc7.orig/arch/ppc/Kconfig
+++ linux-2.6.23-rc7/arch/ppc/Kconfig
@@ -1460,3 +1460,5 @@ source "arch/ppc/Kconfig.debug"
 source "security/Kconfig"
 
 source "crypto/Kconfig"
+
+source "samples/Kconfig"
--- linux-2.6.23-rc7.orig/arch/s390/Kconfig
+++ linux-2.6.23-rc7/arch/s390/Kconfig
@@ -551,4 +551,6 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+source "samples/Kconfig"
+
 source "lib/Kconfig"
--- linux-2.6.23-rc7.orig/arch/sh/Kconfig
+++ linux-2.6.23-rc7/arch/sh/Kconfig
@@ -739,4 +739,6 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+source "samples/Kconfig"
+
 source "lib/Kconfig"
--- linux-2.6.23-rc7.orig/arch/sh64/Kconfig
+++ linux-2.6.23-rc7/arch/sh64/Kconfig
@@ -293,6 +293,8 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+source "samples/Kconfig"
+
 source "lib/Kconfig"
 
 #
--- linux-2.6.23-rc7.orig/arch/sparc/Kconfig
+++ linux-2.6.23-rc7/arch/sparc/Kconfig
@@ -333,4 +333,6 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+source "samples/Kconfig"
+
 source "lib/Kconfig"
--- linux-2.6.23-rc7.orig/arch/sparc64/Kconfig
+++ linux-2.6.23-rc7/arch/sparc64/Kconfig
@@ -482,4 +482,6 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+source "samples/Kconfig"
+
 source "lib/Kconfig"
--- linux-2.6.23-rc7.orig/arch/um/Kconfig
+++ linux-2.6.23-rc7/arch/um/Kconfig
@@ -320,6 +320,8 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+source "samples/Kconfig"
+
 source "lib/Kconfig"
 
 source "drivers/scsi/Kconfig"
--- linux-2.6.23-rc7.orig/arch/v850/Kconfig
+++ linux-2.6.23-rc7/arch/v850/Kconfig
@@ -337,6 +337,8 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+source "samples/Kconfig"
+
 source "lib/Kconfig"
 
 #############################################################################
--- linux-2.6.23-rc7.orig/arch/x86_64/Kconfig
+++ linux-2.6.23-rc7/arch/x86_64/Kconfig
@@ -805,4 +805,6 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
+source "samples/Kconfig"
+
 source "lib/Kconfig"
--- linux-2.6.23-rc7.orig/arch/xtensa/Kconfig
+++ linux-2.6.23-rc7/arch/xtensa/Kconfig
@@ -257,6 +257,7 @@ source "security/Kconfig"
 
 source "crypto/Kconfig"
 
-source "lib/Kconfig"
+source "samples/Kconfig"
 
+source "lib/Kconfig"
 

Re: [patch 6/7] Linux Kernel Markers - Documentation

[Steven Rostedt]

On Mon, Sep 24, 2007 at 06:50:44PM +0100, Christoph Hellwig wrote:
> On Mon, Sep 24, 2007 at 12:49:56PM -0400, Mathieu Desnoyers wrote:
> > Here is some documentation explaining what is/how to use the Linux
> > Kernel Markers.
> 
> As mentioned in the tracing infrastructure thread I don't think
> putting code into Documentation is a good idea.  Either of you really
> should start a sample/ toplevel directory for this kind of stuff
> including a Kconfig menu etc to be able to build these samples as
> part of an allmodconfig.
>

 looking at Documentation/lguest/

 Oh wait, nothing to see here. Move along please.

 ;-)

 -- Steve

Re: [patch 6/7] Linux Kernel Markers - Documentation

[Mathieu Desnoyers]

* Randy Dunlap (randy.dunlap@oracle.com) wrote:
> On Mon, 24 Sep 2007 17:08:30 -0400 Mathieu Desnoyers wrote:
> 
> > * Randy Dunlap (randy.dunlap@oracle.com) wrote:
> > > On Mon, 24 Sep 2007 11:56:35 -0700 Randy Dunlap wrote:
> > > 
> > > > Christoph Hellwig wrote:
> > > > > On Mon, Sep 24, 2007 at 11:49:15AM -0700, Randy Dunlap wrote:
> > > > >> I think that samples are perfectly fine for documentation and
> > > > >> that the trace example is a good example.  I think that most people
> > > > >> who need something like that would need to customize it for their
> > > > >> specific needs anyway.
> > > > >>
> > > > >> We don't seem to be making progress...
> > > > > 
> > > > > Time to bring in a Tie-Breaker :)
> > > > 
> > > > Yes.  Is anyone else interested?   :(
> > > 
> > > 
> > > I guess that's everyone (except those who are sleeping).
> > > 
> > > Let's not hold up progress.  Just use samples/ for code.
> > 
> > Would you already have the 
> > 
> > Makefile
> > samples/Kconfig
> > samples/Makefile
> > 
> > core code handy per chance ? (and probably Kconfig sourcing in every
> > arch ?)
> 
> Yes.  Here it is.  I'm working on add kprobes to it, but you
> can go ahead with markers also.
> 
> 

Hi Randy,

I got everything working and I'm thinking about posting all this stuff
soon. Do you think your patch (having renamed Kbuild to Makefile) is
ready to post ?

Mathieu

> 
> From: Randy Dunlap <randy.dunlap@oracle.com>
> 
> Begin infrastructure for kernel code samples in the samples/ directory.
> Add its Kconfig and Kbuild files.
> Source its Kconfig file in all arch/ Kconfigs.
> 
> 
> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
> ---
>  Makefile               |   10 +++++++---
>  arch/alpha/Kconfig     |    2 ++
>  arch/arm/Kconfig       |    2 ++
>  arch/avr32/Kconfig     |    2 ++
>  arch/blackfin/Kconfig  |    2 ++
>  arch/cris/Kconfig      |    2 ++
>  arch/frv/Kconfig       |    2 ++
>  arch/h8300/Kconfig     |    2 ++
>  arch/i386/Kconfig      |    2 ++
>  arch/ia64/Kconfig      |    2 ++
>  arch/m32r/Kconfig      |    2 ++
>  arch/m68k/Kconfig      |    2 ++
>  arch/m68knommu/Kconfig |    2 ++
>  arch/mips/Kconfig      |    2 ++
>  arch/parisc/Kconfig    |    2 ++
>  arch/powerpc/Kconfig   |    2 ++
>  arch/ppc/Kconfig       |    2 ++
>  arch/s390/Kconfig      |    2 ++
>  arch/sh/Kconfig        |    2 ++
>  arch/sh64/Kconfig      |    2 ++
>  arch/sparc/Kconfig     |    2 ++
>  arch/sparc64/Kconfig   |    2 ++
>  arch/um/Kconfig        |    2 ++
>  arch/v850/Kconfig      |    2 ++
>  arch/x86_64/Kconfig    |    2 ++
>  arch/xtensa/Kconfig    |    3 ++-
>  samples/Kbuild         |    2 ++
>  samples/Kconfig        |   11 +++++++++++
>  28 files changed, 70 insertions(+), 4 deletions(-)
> 
> --- linux-2.6.23-rc7.orig/Makefile
> +++ linux-2.6.23-rc7/Makefile
> @@ -436,6 +436,7 @@ drivers-y	:= drivers/ sound/
>  net-y		:= net/
>  libs-y		:= lib/
>  core-y		:= usr/
> +samples-y	:= samples/
>  endif # KBUILD_EXTMOD
>  
>  ifeq ($(dot-config),1)
> @@ -564,10 +565,12 @@ core-y		+= kernel/ mm/ fs/ ipc/ security
>  
>  vmlinux-dirs	:= $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \
>  		     $(core-y) $(core-m) $(drivers-y) $(drivers-m) \
> -		     $(net-y) $(net-m) $(libs-y) $(libs-m)))
> +		     $(net-y) $(net-m) $(libs-y) $(libs-m))	\
> +		     $(samples-y) $(samples-m))
> +
>  
>  vmlinux-alldirs	:= $(sort $(vmlinux-dirs) $(patsubst %/,%,$(filter %/, \
> -		     $(init-n) $(init-) \
> +		     $(init-n) $(init-) $(samples-n) $(samples-) \
>  		     $(core-n) $(core-) $(drivers-n) $(drivers-) \
>  		     $(net-n)  $(net-)  $(libs-n)    $(libs-))))
>  
> @@ -578,6 +581,7 @@ net-y		:= $(patsubst %/, %/built-in.o, $
>  libs-y1		:= $(patsubst %/, %/lib.a, $(libs-y))
>  libs-y2		:= $(patsubst %/, %/built-in.o, $(libs-y))
>  libs-y		:= $(libs-y1) $(libs-y2)
> +samples-y	:= $(patsubst %/, %/built-in.o, $(samples-y))
>  
>  # Build vmlinux
>  # ---------------------------------------------------------------------------
> @@ -607,7 +611,7 @@ libs-y		:= $(libs-y1) $(libs-y2)
>  # System.map is generated to document addresses of all kernel symbols
>  
>  vmlinux-init := $(head-y) $(init-y)
> -vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y)
> +vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y) $(samples-y)
>  vmlinux-all  := $(vmlinux-init) $(vmlinux-main)
>  vmlinux-lds  := arch/$(ARCH)/kernel/vmlinux.lds
>  export KBUILD_VMLINUX_OBJS := $(vmlinux-all)
> --- /dev/null
> +++ linux-2.6.23-rc7/samples/Kbuild
> @@ -0,0 +1,2 @@
> +# Makefile for Linux samples code
> +
> --- /dev/null
> +++ linux-2.6.23-rc7/samples/Kconfig
> @@ -0,0 +1,11 @@
> +# samples/Kconfig
> +
> +menuconfig SAMPLES
> +	bool "Sample kernel code"
> +	help
> +	  You can build and test sample kernel code here.
> +
> +if SAMPLES
> +
> +
> +endif # SAMPLES
> --- linux-2.6.23-rc7.orig/arch/alpha/Kconfig
> +++ linux-2.6.23-rc7/arch/alpha/Kconfig
> @@ -669,5 +669,7 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> +source "samples/Kconfig"
> +
>  source "lib/Kconfig"
>  
> --- linux-2.6.23-rc7.orig/arch/arm/Kconfig
> +++ linux-2.6.23-rc7/arch/arm/Kconfig
> @@ -1067,4 +1067,6 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> +source "samples/Kconfig"
> +
>  source "lib/Kconfig"
> --- linux-2.6.23-rc7.orig/arch/avr32/Kconfig
> +++ linux-2.6.23-rc7/arch/avr32/Kconfig
> @@ -237,4 +237,6 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> +source "samples/Kconfig"
> +
>  source "lib/Kconfig"
> --- linux-2.6.23-rc7.orig/arch/blackfin/Kconfig
> +++ linux-2.6.23-rc7/arch/blackfin/Kconfig
> @@ -1012,4 +1012,6 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> +source "samples/Kconfig"
> +
>  source "lib/Kconfig"
> --- linux-2.6.23-rc7.orig/arch/cris/Kconfig
> +++ linux-2.6.23-rc7/arch/cris/Kconfig
> @@ -202,4 +202,6 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> +source "samples/Kconfig"
> +
>  source "lib/Kconfig"
> --- linux-2.6.23-rc7.orig/arch/frv/Kconfig
> +++ linux-2.6.23-rc7/arch/frv/Kconfig
> @@ -381,4 +381,6 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> +source "samples/Kconfig"
> +
>  source "lib/Kconfig"
> --- linux-2.6.23-rc7.orig/arch/h8300/Kconfig
> +++ linux-2.6.23-rc7/arch/h8300/Kconfig
> @@ -229,4 +229,6 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> +source "samples/Kconfig"
> +
>  source "lib/Kconfig"
> --- linux-2.6.23-rc7.orig/arch/i386/Kconfig
> +++ linux-2.6.23-rc7/arch/i386/Kconfig
> @@ -1260,6 +1260,8 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> +source "samples/Kconfig"
> +
>  source "lib/Kconfig"
>  
>  #
> --- linux-2.6.23-rc7.orig/arch/ia64/Kconfig
> +++ linux-2.6.23-rc7/arch/ia64/Kconfig
> @@ -594,3 +594,5 @@ source "arch/ia64/Kconfig.debug"
>  source "security/Kconfig"
>  
>  source "crypto/Kconfig"
> +
> +source "samples/Kconfig"
> --- linux-2.6.23-rc7.orig/arch/m32r/Kconfig
> +++ linux-2.6.23-rc7/arch/m32r/Kconfig
> @@ -434,4 +434,6 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> +source "samples/Kconfig"
> +
>  source "lib/Kconfig"
> --- linux-2.6.23-rc7.orig/arch/m68k/Kconfig
> +++ linux-2.6.23-rc7/arch/m68k/Kconfig
> @@ -689,4 +689,6 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> +source "samples/Kconfig"
> +
>  source "lib/Kconfig"
> --- linux-2.6.23-rc7.orig/arch/m68knommu/Kconfig
> +++ linux-2.6.23-rc7/arch/m68knommu/Kconfig
> @@ -702,4 +702,6 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> +source "samples/Kconfig"
> +
>  source "lib/Kconfig"
> --- linux-2.6.23-rc7.orig/arch/mips/Kconfig
> +++ linux-2.6.23-rc7/arch/mips/Kconfig
> @@ -1924,4 +1924,6 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> +source "samples/Kconfig"
> +
>  source "lib/Kconfig"
> --- linux-2.6.23-rc7.orig/arch/parisc/Kconfig
> +++ linux-2.6.23-rc7/arch/parisc/Kconfig
> @@ -275,4 +275,6 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> +source "samples/Kconfig"
> +
>  source "lib/Kconfig"
> --- linux-2.6.23-rc7.orig/arch/powerpc/Kconfig
> +++ linux-2.6.23-rc7/arch/powerpc/Kconfig
> @@ -662,3 +662,5 @@ config KEYS_COMPAT
>  	default y
>  
>  source "crypto/Kconfig"
> +
> +source "samples/Kconfig"
> --- linux-2.6.23-rc7.orig/arch/ppc/Kconfig
> +++ linux-2.6.23-rc7/arch/ppc/Kconfig
> @@ -1460,3 +1460,5 @@ source "arch/ppc/Kconfig.debug"
>  source "security/Kconfig"
>  
>  source "crypto/Kconfig"
> +
> +source "samples/Kconfig"
> --- linux-2.6.23-rc7.orig/arch/s390/Kconfig
> +++ linux-2.6.23-rc7/arch/s390/Kconfig
> @@ -551,4 +551,6 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> +source "samples/Kconfig"
> +
>  source "lib/Kconfig"
> --- linux-2.6.23-rc7.orig/arch/sh/Kconfig
> +++ linux-2.6.23-rc7/arch/sh/Kconfig
> @@ -739,4 +739,6 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> +source "samples/Kconfig"
> +
>  source "lib/Kconfig"
> --- linux-2.6.23-rc7.orig/arch/sh64/Kconfig
> +++ linux-2.6.23-rc7/arch/sh64/Kconfig
> @@ -293,6 +293,8 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> +source "samples/Kconfig"
> +
>  source "lib/Kconfig"
>  
>  #
> --- linux-2.6.23-rc7.orig/arch/sparc/Kconfig
> +++ linux-2.6.23-rc7/arch/sparc/Kconfig
> @@ -333,4 +333,6 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> +source "samples/Kconfig"
> +
>  source "lib/Kconfig"
> --- linux-2.6.23-rc7.orig/arch/sparc64/Kconfig
> +++ linux-2.6.23-rc7/arch/sparc64/Kconfig
> @@ -482,4 +482,6 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> +source "samples/Kconfig"
> +
>  source "lib/Kconfig"
> --- linux-2.6.23-rc7.orig/arch/um/Kconfig
> +++ linux-2.6.23-rc7/arch/um/Kconfig
> @@ -320,6 +320,8 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> +source "samples/Kconfig"
> +
>  source "lib/Kconfig"
>  
>  source "drivers/scsi/Kconfig"
> --- linux-2.6.23-rc7.orig/arch/v850/Kconfig
> +++ linux-2.6.23-rc7/arch/v850/Kconfig
> @@ -337,6 +337,8 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> +source "samples/Kconfig"
> +
>  source "lib/Kconfig"
>  
>  #############################################################################
> --- linux-2.6.23-rc7.orig/arch/x86_64/Kconfig
> +++ linux-2.6.23-rc7/arch/x86_64/Kconfig
> @@ -805,4 +805,6 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> +source "samples/Kconfig"
> +
>  source "lib/Kconfig"
> --- linux-2.6.23-rc7.orig/arch/xtensa/Kconfig
> +++ linux-2.6.23-rc7/arch/xtensa/Kconfig
> @@ -257,6 +257,7 @@ source "security/Kconfig"
>  
>  source "crypto/Kconfig"
>  
> -source "lib/Kconfig"
> +source "samples/Kconfig"
>  
> +source "lib/Kconfig"
>  

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: [patch 6/7] Linux Kernel Markers - Documentation

[Randy Dunlap]

Mathieu Desnoyers wrote:
> * Randy Dunlap (randy.dunlap@oracle.com) wrote:
>> On Mon, 24 Sep 2007 17:08:30 -0400 Mathieu Desnoyers wrote:
>>
>>> * Randy Dunlap (randy.dunlap@oracle.com) wrote:
>>>> On Mon, 24 Sep 2007 11:56:35 -0700 Randy Dunlap wrote:
>>>>
>>>>> Christoph Hellwig wrote:
>>>>>> On Mon, Sep 24, 2007 at 11:49:15AM -0700, Randy Dunlap wrote:
>>>>>>> I think that samples are perfectly fine for documentation and
>>>>>>> that the trace example is a good example.  I think that most people
>>>>>>> who need something like that would need to customize it for their
>>>>>>> specific needs anyway.
>>>>>>>
>>>>>>> We don't seem to be making progress...
>>>>>> Time to bring in a Tie-Breaker :)
>>>>> Yes.  Is anyone else interested?   :(
>>>>
>>>> I guess that's everyone (except those who are sleeping).
>>>>
>>>> Let's not hold up progress.  Just use samples/ for code.
>>> Would you already have the 
>>>
>>> Makefile
>>> samples/Kconfig
>>> samples/Makefile
>>>
>>> core code handy per chance ? (and probably Kconfig sourcing in every
>>> arch ?)
>> Yes.  Here it is.  I'm working on add kprobes to it, but you
>> can go ahead with markers also.
>>
>>
> 
> Hi Randy,
> 
> I got everything working and I'm thinking about posting all this stuff
> soon. Do you think your patch (having renamed Kbuild to Makefile) is
> ready to post ?

Yes, AFAIK it is.  Do you want me to resend it or do you want to
make it patch M/N in your patches?

-- 
~Randy
Phaedrus says that Quality is about caring.

Re: [patch 6/7] Linux Kernel Markers - Documentation

[Christoph Hellwig]

On Mon, Sep 24, 2007 at 09:31:08PM -0400, Steven Rostedt wrote:
>  looking at Documentation/lguest/
> 
>  Oh wait, nothing to see here. Move along please.

lguest is an even bigger nightmare.  It's userspace code, but we can't
move it because it pokes into non-exported headers.

Re: [patch 6/7] Linux Kernel Markers - Documentation

[Mathieu Desnoyers]

* Randy Dunlap (randy.dunlap@oracle.com) wrote:
> Mathieu Desnoyers wrote:
> >* Randy Dunlap (randy.dunlap@oracle.com) wrote:
> >>On Mon, 24 Sep 2007 17:08:30 -0400 Mathieu Desnoyers wrote:
> >>
> >>>* Randy Dunlap (randy.dunlap@oracle.com) wrote:
> >>>>On Mon, 24 Sep 2007 11:56:35 -0700 Randy Dunlap wrote:
> >>>>
> >>>>>Christoph Hellwig wrote:
> >>>>>>On Mon, Sep 24, 2007 at 11:49:15AM -0700, Randy Dunlap wrote:
> >>>>>>>I think that samples are perfectly fine for documentation and
> >>>>>>>that the trace example is a good example.  I think that most people
> >>>>>>>who need something like that would need to customize it for their
> >>>>>>>specific needs anyway.
> >>>>>>>
> >>>>>>>We don't seem to be making progress...
> >>>>>>Time to bring in a Tie-Breaker :)
> >>>>>Yes.  Is anyone else interested?   :(
> >>>>
> >>>>I guess that's everyone (except those who are sleeping).
> >>>>
> >>>>Let's not hold up progress.  Just use samples/ for code.
> >>>Would you already have the 
> >>>
> >>>Makefile
> >>>samples/Kconfig
> >>>samples/Makefile
> >>>
> >>>core code handy per chance ? (and probably Kconfig sourcing in every
> >>>arch ?)
> >>Yes.  Here it is.  I'm working on add kprobes to it, but you
> >>can go ahead with markers also.
> >>
> >>
> >
> >Hi Randy,
> >
> >I got everything working and I'm thinking about posting all this stuff
> >soon. Do you think your patch (having renamed Kbuild to Makefile) is
> >ready to post ?
> 
> Yes, AFAIK it is.  Do you want me to resend it or do you want to
> make it patch M/N in your patches?
> 

I'll include it with my patches. Thanks!

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68