Re: [Patch 1/2] Trace code and documentation (updated)
Christoph Hellwig wrote: Your mailer wrapper the patch so I can't actually apply it to start playing with the patch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ This one should be better: http://lkml.org/lkml/2007/9/22/4 You already responded, so you must have found it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] Trace code and documentation (updated)
Christoph Hellwig wrote: Your mailer wrapper the patch so I can't actually apply it to start playing with the patch. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ This one should be better: http://lkml.org/lkml/2007/9/22/4 You already responded, so you must have found it. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] Trace code and documentation (updated)
Your mailer wrapper the patch so I can't actually apply it to start playing with the patch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] Trace code and documentation (updated)
Your mailer wrapper the patch so I can't actually apply it to start playing with the patch. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] Trace code and documentation (updated)
On Fri, 21 Sep 2007 14:48:14 -0700 David J. Wilder wrote:
> I updated the example code to eliminate the use of the temp print buffer
> and the use of NR_CPU.
>
> Please see previous postings for more information and patch
> dependencies.
> http://lkml.org/lkml/2007/9/19/4 (PATCH 0/2)
> http://lkml.org/lkml/2007/9/19/6 (PATCH 2/2)
>
> -
> Trace - Provides tracing primitives
>
> Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]>
> Signed-off-by: Martin Hunt <[EMAIL PROTECTED]>
> Signed-off-by: David Wilder <[EMAIL PROTECTED]>
> ---
> 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 +++
> +++
^^^ unexpected line break (similar break causes 'patch' problems later)
> 8 files changed, 981 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/trace/src/Makefile
> b/Documentation/trace/src/Makefile
> new file mode 100644
> index 000..9ee4c72
> --- /dev/null
> +++ b/Documentation/trace/src/Makefile
> @@ -0,0 +1,7 @@
> +obj-m := fork_trace.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
> diff --git a/Documentation/trace/src/README
> b/Documentation/trace/src/README
> new file mode 100644
> index 000..f538491
> --- /dev/null
> +++ b/Documentation/trace/src/README
> @@ -0,0 +1,18 @@
> +This small sample module creates a trace channel. It places a kprobe
> +on the function do_fork(). The value of current->pid is written to
> +the trace channel each time the kprobe is hit..
> +
> +How to run the example:
> +$ mount -t debugfs /debug
> +$ make
> +$ insmod fork_trace.ko
> +
> +To view the data produced by the module:
> +$ cat /debug/trace_example/do_fork/trace0
> +
> +Remove the module.
> +$ rmmod fork_trace
> +
> +The function trace_cleanup() is called when the module
> +is removed. This will cause the TRACE channel to be destroyed and the
> +corresponding files to disappear from the debug file system.
> diff --git a/Documentation/trace/src/fork_trace.c
> b/Documentation/trace/src/fork_trace.c
> new file mode 100644
> index 000..aae3196
> --- /dev/null
> +++ b/Documentation/trace/src/fork_trace.c
> @@ -0,0 +1,119 @@
> +/*
> + * An example of using trace in a kprobes module
> + *
> + * Copyright (C) 2007 IBM Inc.
> + *
> + * David Wilder <[EMAIL PROTECTED]>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * 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., 51 Franklin St, Fifth Floor, Boston, MA
> 02110-1301 USA
^^^ here: patch --dryrun says:
patch: malformed patch at line 92: 02110-1301 USA
You can also see this at
http://lkml.org/lkml/2007/9/21/431
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#define USE_GLOBAL_BUFFERS 1
> +#define USE_FLIGHT 1
> +
> +#define PROBE_POINT "do_fork"
> +
> +static struct kprobe kp;
> +static struct trace_info *kprobes_trace;
> +
> +#ifdef USE_GLOBAL_BUFFERS
> +static DEFINE_SPINLOCK(trace_lock);
> +#endif
> +
> +/*
> + * Send formated trace data to trace channel.
formatted
> + * @note Preemption must be disabled to use this.
> + */
> +static void trace_printf(struct trace_info *trace, const char
> *format, ...)
> +{
> + va_list ap, aq;
> + char *record;
> + unsigned long flags;
> + int len;
> +
> + if (!trace)
> + return;
> +
> +#ifdef USE_GLOBAL_BUFFERS
> + spin_lock_irqsave(_lock, flags);
> +#endif
> + if (trace_running(trace)) {
> + va_start(ap, format);
> + va_copy(aq, ap);
> + len = vsnprintf(NULL, 0, format, aq);
> + va_end(aq);
> + record = relay_reserve(trace->rchan, ++len);
> + if (record)
> + vsnprintf(record, len, format, ap);
> + va_end(ap);
> + }
> +#ifdef USE_GLOBAL_BUFFERS
> + spin_unlock_irqrestore(_lock, flags);
> +#endif
> +}
> +
> +static int handler_pre(struct kprobe *p, struct pt_regs *regs)
> +{
> + rcu_read_lock();
> + trace_printf(kprobes_trace, "%d\n", current->pid);
> +
Re: [Patch 1/2] Trace code and documentation (updated)
On Fri, 21 Sep 2007 14:48:14 -0700 David J. Wilder wrote:
I updated the example code to eliminate the use of the temp print buffer
and the use of NR_CPU.
Please see previous postings for more information and patch
dependencies.
http://lkml.org/lkml/2007/9/19/4 (PATCH 0/2)
http://lkml.org/lkml/2007/9/19/6 (PATCH 2/2)
---start of patch--
Trace - Provides tracing primitives
Signed-off-by: Tom Zanussi [EMAIL PROTECTED]
Signed-off-by: Martin Hunt [EMAIL PROTECTED]
Signed-off-by: David Wilder [EMAIL PROTECTED]
---
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 +++
+++
^^^ unexpected line break (similar break causes 'patch' problems later)
8 files changed, 981 insertions(+), 0 deletions(-)
diff --git a/Documentation/trace/src/Makefile
b/Documentation/trace/src/Makefile
new file mode 100644
index 000..9ee4c72
--- /dev/null
+++ b/Documentation/trace/src/Makefile
@@ -0,0 +1,7 @@
+obj-m := fork_trace.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
diff --git a/Documentation/trace/src/README
b/Documentation/trace/src/README
new file mode 100644
index 000..f538491
--- /dev/null
+++ b/Documentation/trace/src/README
@@ -0,0 +1,18 @@
+This small sample module creates a trace channel. It places a kprobe
+on the function do_fork(). The value of current-pid is written to
+the trace channel each time the kprobe is hit..
+
+How to run the example:
+$ mount -t debugfs /debug
+$ make
+$ insmod fork_trace.ko
+
+To view the data produced by the module:
+$ cat /debug/trace_example/do_fork/trace0
+
+Remove the module.
+$ rmmod fork_trace
+
+The function trace_cleanup() is called when the module
+is removed. This will cause the TRACE channel to be destroyed and the
+corresponding files to disappear from the debug file system.
diff --git a/Documentation/trace/src/fork_trace.c
b/Documentation/trace/src/fork_trace.c
new file mode 100644
index 000..aae3196
--- /dev/null
+++ b/Documentation/trace/src/fork_trace.c
@@ -0,0 +1,119 @@
+/*
+ * An example of using trace in a kprobes module
+ *
+ * Copyright (C) 2007 IBM Inc.
+ *
+ * David Wilder [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * 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., 51 Franklin St, Fifth Floor, Boston, MA
02110-1301 USA
^^^ here: patch --dryrun says:
patch: malformed patch at line 92: 02110-1301 USA
You can also see this at
http://lkml.org/lkml/2007/9/21/431
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/kprobes.h
+#include linux/trace.h
+
+#define USE_GLOBAL_BUFFERS 1
+#define USE_FLIGHT 1
+
+#define PROBE_POINT do_fork
+
+static struct kprobe kp;
+static struct trace_info *kprobes_trace;
+
+#ifdef USE_GLOBAL_BUFFERS
+static DEFINE_SPINLOCK(trace_lock);
+#endif
+
+/*
+ * Send formated trace data to trace channel.
formatted
+ * @note Preemption must be disabled to use this.
+ */
+static void trace_printf(struct trace_info *trace, const char
*format, ...)
+{
+ va_list ap, aq;
+ char *record;
+ unsigned long flags;
+ int len;
+
+ if (!trace)
+ return;
+
+#ifdef USE_GLOBAL_BUFFERS
+ spin_lock_irqsave(trace_lock, flags);
+#endif
+ if (trace_running(trace)) {
+ va_start(ap, format);
+ va_copy(aq, ap);
+ len = vsnprintf(NULL, 0, format, aq);
+ va_end(aq);
+ record = relay_reserve(trace-rchan, ++len);
+ if (record)
+ vsnprintf(record, len, format, ap);
+ va_end(ap);
+ }
+#ifdef USE_GLOBAL_BUFFERS
+ spin_unlock_irqrestore(trace_lock, flags);
+#endif
+}
+
+static int handler_pre(struct kprobe *p, struct pt_regs *regs)
+{
+ rcu_read_lock();
+ trace_printf(kprobes_trace, %d\n, current-pid);
+ rcu_read_unlock();
+ return 0;
+}
+
+int init_module(void)
+{
+ int ret;
+
Re: [Patch 1/2] Trace code and documentation (updated)
On Wed, 19 Sep 2007 17:20:18 +0100 Christoph Hellwig wrote: > On Wed, Sep 19, 2007 at 07:14:47AM -0700, David Wilder wrote: > > I agree with you; however, this is in the example code in the > > Documentation directory, It is not part of the trace code. The example > > was just meant to be a demonstration of how the interface works. > > So we tell people to write bad code? Wonderful.. > > And while we're at it can we please stop the dumb idea to put example > code into Documentation? If example code doesn't get build during a > make oldconfig it will bitrot real fast and not be useful at all. That's why they exmaples should not be hidden/embedded in .txt files; they should be standalone .c files with makefiles etc. I've built and corrected several of them, but they would be more likely to be kept up-to-date if they are more available in standalone files. and they can be taken out of Documentation/ whenever they go into util-linux-ng or elsewhere. Let's get the order correct. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] Trace code and documentation (updated)
On Wed, Sep 19, 2007 at 07:48:45PM +0200, Sam Ravnborg wrote: > > Well, this is kernel code - so util-linux is not the solution here > > obviously :) > > Can you sketch what you have in mind. > We right now have said we wnated to: > 1) include a framework for executing simple new-syscall-test-stubs > 2) have a nice place for kernel example code > > I could come up with something but I expect you already have something > in your mind where to put stuff. > If I have a rough idea I can start looking into the kbuild bits of it. > Not that I will have it ready within the next two weeks but nice buffer > when I anyway drop sleeping.. I think for samples we just want a samples/ toplevel directory with normal Kbuild and Kconfig files. Not any different from drivers or filesystems, just a new hiearchary. tests stuff was rather disliked by Linus, so I wonder wether we should go ahead with it. We'd need a test driver like expect to driver the testcases. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] Trace code and documentation (updated)
On Wed, Sep 19, 2007 at 05:55:07PM +0100, Christoph Hellwig wrote: > On Wed, Sep 19, 2007 at 09:52:23AM -0700, Randy Dunlap wrote: > > That's why they exmaples should not be hidden/embedded in .txt files; > > they should be standalone .c files with makefiles etc. > > Yes. And most importantly integrated with the kernel build system. > > > and they can be taken out of Documentation/ whenever they go into > > util-linux-ng or elsewhere. Let's get the order correct. > > Well, this is kernel code - so util-linux is not the solution here > obviously :) Can you sketch what you have in mind. We right now have said we wnated to: 1) include a framework for executing simple new-syscall-test-stubs 2) have a nice place for kernel example code I could come up with something but I expect you already have something in your mind where to put stuff. If I have a rough idea I can start looking into the kbuild bits of it. Not that I will have it ready within the next two weeks but nice buffer when I anyway drop sleeping.. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] Trace code and documentation (updated)
Randy Dunlap wrote: On Wed, 19 Sep 2007 17:20:18 +0100 Christoph Hellwig wrote: On Wed, Sep 19, 2007 at 07:14:47AM -0700, David Wilder wrote: I agree with you; however, this is in the example code in the Documentation directory, It is not part of the trace code. The example was just meant to be a demonstration of how the interface works. So we tell people to write bad code? Wonderful.. And while we're at it can we please stop the dumb idea to put example code into Documentation? If example code doesn't get build during a make oldconfig it will bitrot real fast and not be useful at all. That's why they exmaples should not be hidden/embedded in .txt files; they should be standalone .c files with makefiles etc. I've built and corrected several of them, but they would be more likely to be kept up-to-date if they are more available in standalone files. and they can be taken out of Documentation/ whenever they go into util-linux-ng or elsewhere. Let's get the order correct. --- ~Randy IMHO keeping example code as standalone files under Documentation/* make it easy to build an play with. I like it better than keeping it on some project website where it is even less likely to maintained. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] Trace code and documentation (updated)
On Wed, Sep 19, 2007 at 09:52:23AM -0700, Randy Dunlap wrote: > That's why they exmaples should not be hidden/embedded in .txt files; > they should be standalone .c files with makefiles etc. Yes. And most importantly integrated with the kernel build system. > and they can be taken out of Documentation/ whenever they go into > util-linux-ng or elsewhere. Let's get the order correct. Well, this is kernel code - so util-linux is not the solution here obviously :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] Trace code and documentation (updated)
On Wed, Sep 19, 2007 at 07:14:47AM -0700, David Wilder wrote: > I agree with you; however, this is in the example code in the > Documentation directory, It is not part of the trace code. The example > was just meant to be a demonstration of how the interface works. So we tell people to write bad code? Wonderful.. And while we're at it can we please stop the dumb idea to put example code into Documentation? If example code doesn't get build during a make oldconfig it will bitrot real fast and not be useful at all. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] Trace code and documentation (updated)
> I agree with you; however, this is in the example code in the > Documentation directory, It is not part of the trace code. The example > was just meant to be a demonstration of how the interface works. That's not a good excuse. In fact it's a very bad one. Especially example code needs to be correct because it'll be likely copied a lot. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] Trace code and documentation (updated)
Andi Kleen wrote: "David J. Wilder" <[EMAIL PROTECTED]> writes: Not having read the whole thing; just something I noticed. Gut feeling is that you have too many knobs and options and some overengineering though -- simplifying it would be a good thing. + +#define TRACE_PRINTF_TMPBUF_SIZE (1024) +static char trace_tmpbuf[NR_CPUS][TRACE_PRINTF_TMPBUF_SIZE]; That definitely needs to be a per CPU variable. Imagine what happens on a NR_CPUS==4096 kernel. In general when you have a NR_CPUS indexed array you're likely doing something wrong. Yes there are still places in the main tree who do that, but most of them need to be fixed. I agree with you; however, this is in the example code in the Documentation directory, It is not part of the trace code. The example was just meant to be a demonstration of how the interface works. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] Trace code and documentation (updated)
"David J. Wilder" <[EMAIL PROTECTED]> writes: Not having read the whole thing; just something I noticed. Gut feeling is that you have too many knobs and options and some overengineering though -- simplifying it would be a good thing. > + > +#define TRACE_PRINTF_TMPBUF_SIZE (1024) > +static char trace_tmpbuf[NR_CPUS][TRACE_PRINTF_TMPBUF_SIZE]; That definitely needs to be a per CPU variable. Imagine what happens on a NR_CPUS==4096 kernel. In general when you have a NR_CPUS indexed array you're likely doing something wrong. Yes there are still places in the main tree who do that, but most of them need to be fixed. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] Trace code and documentation (updated)
David J. Wilder [EMAIL PROTECTED] writes: Not having read the whole thing; just something I noticed. Gut feeling is that you have too many knobs and options and some overengineering though -- simplifying it would be a good thing. + +#define TRACE_PRINTF_TMPBUF_SIZE (1024) +static char trace_tmpbuf[NR_CPUS][TRACE_PRINTF_TMPBUF_SIZE]; That definitely needs to be a per CPU variable. Imagine what happens on a NR_CPUS==4096 kernel. In general when you have a NR_CPUS indexed array you're likely doing something wrong. Yes there are still places in the main tree who do that, but most of them need to be fixed. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] Trace code and documentation (updated)
Andi Kleen wrote: David J. Wilder [EMAIL PROTECTED] writes: Not having read the whole thing; just something I noticed. Gut feeling is that you have too many knobs and options and some overengineering though -- simplifying it would be a good thing. + +#define TRACE_PRINTF_TMPBUF_SIZE (1024) +static char trace_tmpbuf[NR_CPUS][TRACE_PRINTF_TMPBUF_SIZE]; That definitely needs to be a per CPU variable. Imagine what happens on a NR_CPUS==4096 kernel. In general when you have a NR_CPUS indexed array you're likely doing something wrong. Yes there are still places in the main tree who do that, but most of them need to be fixed. I agree with you; however, this is in the example code in the Documentation directory, It is not part of the trace code. The example was just meant to be a demonstration of how the interface works. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] Trace code and documentation (updated)
I agree with you; however, this is in the example code in the Documentation directory, It is not part of the trace code. The example was just meant to be a demonstration of how the interface works. That's not a good excuse. In fact it's a very bad one. Especially example code needs to be correct because it'll be likely copied a lot. -Andi - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] Trace code and documentation (updated)
On Wed, Sep 19, 2007 at 07:14:47AM -0700, David Wilder wrote: I agree with you; however, this is in the example code in the Documentation directory, It is not part of the trace code. The example was just meant to be a demonstration of how the interface works. So we tell people to write bad code? Wonderful.. And while we're at it can we please stop the dumb idea to put example code into Documentation? If example code doesn't get build during a make oldconfig it will bitrot real fast and not be useful at all. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] Trace code and documentation (updated)
On Wed, Sep 19, 2007 at 09:52:23AM -0700, Randy Dunlap wrote: That's why they exmaples should not be hidden/embedded in .txt files; they should be standalone .c files with makefiles etc. Yes. And most importantly integrated with the kernel build system. and they can be taken out of Documentation/ whenever they go into util-linux-ng or elsewhere. Let's get the order correct. Well, this is kernel code - so util-linux is not the solution here obviously :) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] Trace code and documentation (updated)
Randy Dunlap wrote: On Wed, 19 Sep 2007 17:20:18 +0100 Christoph Hellwig wrote: On Wed, Sep 19, 2007 at 07:14:47AM -0700, David Wilder wrote: I agree with you; however, this is in the example code in the Documentation directory, It is not part of the trace code. The example was just meant to be a demonstration of how the interface works. So we tell people to write bad code? Wonderful.. And while we're at it can we please stop the dumb idea to put example code into Documentation? If example code doesn't get build during a make oldconfig it will bitrot real fast and not be useful at all. That's why they exmaples should not be hidden/embedded in .txt files; they should be standalone .c files with makefiles etc. I've built and corrected several of them, but they would be more likely to be kept up-to-date if they are more available in standalone files. and they can be taken out of Documentation/ whenever they go into util-linux-ng or elsewhere. Let's get the order correct. --- ~Randy IMHO keeping example code as standalone files under Documentation/* make it easy to build an play with. I like it better than keeping it on some project website where it is even less likely to maintained. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] Trace code and documentation (updated)
On Wed, Sep 19, 2007 at 05:55:07PM +0100, Christoph Hellwig wrote: On Wed, Sep 19, 2007 at 09:52:23AM -0700, Randy Dunlap wrote: That's why they exmaples should not be hidden/embedded in .txt files; they should be standalone .c files with makefiles etc. Yes. And most importantly integrated with the kernel build system. and they can be taken out of Documentation/ whenever they go into util-linux-ng or elsewhere. Let's get the order correct. Well, this is kernel code - so util-linux is not the solution here obviously :) Can you sketch what you have in mind. We right now have said we wnated to: 1) include a framework for executing simple new-syscall-test-stubs 2) have a nice place for kernel example code I could come up with something but I expect you already have something in your mind where to put stuff. If I have a rough idea I can start looking into the kbuild bits of it. Not that I will have it ready within the next two weeks but nice buffer when I anyway drop sleeping.. Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] Trace code and documentation (updated)
On Wed, Sep 19, 2007 at 07:48:45PM +0200, Sam Ravnborg wrote: Well, this is kernel code - so util-linux is not the solution here obviously :) Can you sketch what you have in mind. We right now have said we wnated to: 1) include a framework for executing simple new-syscall-test-stubs 2) have a nice place for kernel example code I could come up with something but I expect you already have something in your mind where to put stuff. If I have a rough idea I can start looking into the kbuild bits of it. Not that I will have it ready within the next two weeks but nice buffer when I anyway drop sleeping.. I think for samples we just want a samples/ toplevel directory with normal Kbuild and Kconfig files. Not any different from drivers or filesystems, just a new hiearchary. tests stuff was rather disliked by Linus, so I wonder wether we should go ahead with it. We'd need a test driver like expect to driver the testcases. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch 1/2] Trace code and documentation (updated)
On Wed, 19 Sep 2007 17:20:18 +0100 Christoph Hellwig wrote: On Wed, Sep 19, 2007 at 07:14:47AM -0700, David Wilder wrote: I agree with you; however, this is in the example code in the Documentation directory, It is not part of the trace code. The example was just meant to be a demonstration of how the interface works. So we tell people to write bad code? Wonderful.. And while we're at it can we please stop the dumb idea to put example code into Documentation? If example code doesn't get build during a make oldconfig it will bitrot real fast and not be useful at all. That's why they exmaples should not be hidden/embedded in .txt files; they should be standalone .c files with makefiles etc. I've built and corrected several of them, but they would be more likely to be kept up-to-date if they are more available in standalone files. and they can be taken out of Documentation/ whenever they go into util-linux-ng or elsewhere. Let's get the order correct. --- ~Randy - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
