Christoph Hellwig wrote:
On Mon, Sep 24, 2007 at 08:38:34AM -0700, David Wilder wrote:
NACK, don't put code into Documentation/. Put it into kernel as it's
actually useful kernel code.
Are you suggesting moving the example code into kernel? Or complaining
about example code in
On Mon, 24 Sep 2007 16:41:14 +0100 Christoph Hellwig wrote:
> On Mon, Sep 24, 2007 at 08:38:34AM -0700, David Wilder wrote:
> > >NACK, don't put code into Documentation/. Put it into kernel as it's
> > >actually useful kernel code.
> >
> > Are you suggesting moving the example code into
On Mon, Sep 24, 2007 at 08:38:34AM -0700, David Wilder wrote:
> >NACK, don't put code into Documentation/. Put it into kernel as it's
> >actually useful kernel code.
>
> Are you suggesting moving the example code into kernel? Or complaining
> about example code in /Documentation?
Both.
Christoph Hellwig wrote:
On Fri, Sep 21, 2007 at 09:23:28PM -0700, David J. Wilder wrote:
My last posting was mangled by my mailer. I hope this one is better.
Also corrected Randy's concerns.
Please see previous posting for more information:
http://lkml.org/lkml/2007/9/19/4 (PATCH 0/2)
Note:
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
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
Christoph Hellwig wrote:
On Fri, Sep 21, 2007 at 09:23:28PM -0700, David J. Wilder wrote:
My last posting was mangled by my mailer. I hope this one is better.
Also corrected Randy's concerns.
Please see previous posting for more information:
http://lkml.org/lkml/2007/9/19/4 (PATCH 0/2)
Note:
On Mon, Sep 24, 2007 at 08:38:34AM -0700, David Wilder wrote:
NACK, don't put code into Documentation/. Put it into kernel as it's
actually useful kernel code.
Are you suggesting moving the example code into kernel? Or complaining
about example code in /Documentation?
Both. example
On Mon, 24 Sep 2007 16:41:14 +0100 Christoph Hellwig wrote:
On Mon, Sep 24, 2007 at 08:38:34AM -0700, David Wilder wrote:
NACK, don't put code into Documentation/. Put it into kernel as it's
actually useful kernel code.
Are you suggesting moving the example code into kernel? Or
Christoph Hellwig wrote:
On Mon, Sep 24, 2007 at 08:38:34AM -0700, David Wilder wrote:
NACK, don't put code into Documentation/. Put it into kernel as it's
actually useful kernel code.
Are you suggesting moving the example code into kernel? Or complaining
about example code in
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
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
On Fri, Sep 21, 2007 at 09:23:28PM -0700, David J. Wilder wrote:
> My last posting was mangled by my mailer. I hope this one is better.
> Also corrected Randy's concerns.
>
> Please see previous posting for more information:
> http://lkml.org/lkml/2007/9/19/4 (PATCH 0/2)
>
> Note: this patch
On Fri, Sep 21, 2007 at 09:23:28PM -0700, David J. Wilder wrote:
My last posting was mangled by my mailer. I hope this one is better.
Also corrected Randy's concerns.
Please see previous posting for more information:
http://lkml.org/lkml/2007/9/19/4 (PATCH 0/2)
Note: this patch requires
My last posting was mangled by my mailer. I hope this one is better.
Also corrected Randy's concerns.
Please see previous posting for more information:
http://lkml.org/lkml/2007/9/19/4 (PATCH 0/2)
Note: this patch requires "[Patch 2/2] Relay reset consumed" is applied.
-
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)
>
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 -
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
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)
My last posting was mangled by my mailer. I hope this one is better.
Also corrected Randy's concerns.
Please see previous posting for more information:
http://lkml.org/lkml/2007/9/19/4 (PATCH 0/2)
Note: this patch requires [Patch 2/2] Relay reset consumed is applied.
-start of
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
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
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
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
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
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
> 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
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
"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
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
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)
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
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
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
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
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
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)
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
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 +
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 +
Hi David,
Interesting work, but I think we could still enhance it. The interesting
things you bring is the trace control though debugfs files, which is
clear and simple. (I did it on top of netlink in LTTng, but I don't
really care about the mechanism, as long as we have the same
flexibility).
*
Hi David,
Interesting work, but I think we could still enhance it. The interesting
things you bring is the trace control though debugfs files, which is
clear and simple. (I did it on top of netlink in LTTng, but I don't
really care about the mechanism, as long as we have the same
flexibility).
*
On Fri, Sep 14, 2007 at 09:49:31PM -0700, David Wilder wrote:
> Sam Ravnborg wrote:
> >Hi David.
> >
> >A random comment to the code.
> >Several of the struct file_operations are not declared static as
> >they should be.
> >
> >Btw. it looks good from a coding style point-of-view.
> >
> >About the
Sam Ravnborg wrote:
Hi David.
A random comment to the code.
Several of the struct file_operations are not declared static as
they should be.
Btw. it looks good from a coding style point-of-view.
About the name what about ktrace??
Sam
Thanks for the comment. I sure don't want to
Andrew Morton wrote:
+/*
+ * Based on blktrace code, Copyright (C) 2006 Jens Axboe <[EMAIL PROTECTED]>
So can we migrate blktrace to using this?
Yes, a blktrace patch is comming.
+ int ret;
+
+ if (trace->flags & TRACE_DISABLE_STATE)
+ return -EINVAL;
+
On Fri, 14 Sep 2007 18:08:40 -0700 Andrew Morton wrote:
> > Trace - Provides tracing primitives
> >
> > ...
> >
> > +config TRACE
> > + bool "Trace setup and control"
> > + select RELAY
> > + select DEBUG_FS
> > + help
> > + This option provides support for the setup, teardown and
> Trace - Provides tracing primitives
>
> ...
>
> +config TRACE
> + bool "Trace setup and control"
> + select RELAY
> + select DEBUG_FS
> + help
> + This option provides support for the setup, teardown and control
> + of tracing channels from kernel code. It also
Hi David.
A random comment to the code.
Several of the struct file_operations are not declared static as
they should be.
Btw. it looks good from a coding style point-of-view.
About the name what about ktrace??
Sam
-
To unsubscribe from this list: send the line "unsubscribe
Hi David.
A random comment to the code.
Several of the struct file_operations are not declared static as
they should be.
Btw. it looks good from a coding style point-of-view.
About the name what about ktrace??
Sam
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
Trace - Provides tracing primitives
...
+config TRACE
+ bool Trace setup and control
+ select RELAY
+ select DEBUG_FS
+ help
+ This option provides support for the setup, teardown and control
+ of tracing channels from kernel code. It also provides trace
+
On Fri, 14 Sep 2007 18:08:40 -0700 Andrew Morton wrote:
Trace - Provides tracing primitives
...
+config TRACE
+ bool Trace setup and control
+ select RELAY
+ select DEBUG_FS
+ help
+ This option provides support for the setup, teardown and control
+ of
Andrew Morton wrote:
+/*
+ * Based on blktrace code, Copyright (C) 2006 Jens Axboe [EMAIL PROTECTED]
So can we migrate blktrace to using this?
Yes, a blktrace patch is comming.
+ int ret;
+
+ if (trace-flags TRACE_DISABLE_STATE)
+ return -EINVAL;
+
Sam Ravnborg wrote:
Hi David.
A random comment to the code.
Several of the struct file_operations are not declared static as
they should be.
Btw. it looks good from a coding style point-of-view.
About the name what about ktrace??
Sam
Thanks for the comment. I sure don't want to
On Fri, Sep 14, 2007 at 09:49:31PM -0700, David Wilder wrote:
Sam Ravnborg wrote:
Hi David.
A random comment to the code.
Several of the struct file_operations are not declared static as
they should be.
Btw. it looks good from a coding style point-of-view.
About the name what about
On Thu, 13 Sep 2007 16:43:16 -0700 David Wilder wrote:
> [it would be easier to review and make sense of the comments
> if the patch were inline instead of attached]
Tom Zanussi <[EMAIL PROTECTED]>
Martin Hunt <[EMAIL PROTECTED]>
David Wilder <[EMAIL PROTECTED]>
Above needs to use
Trace - Provides tracing primitives
Tom Zanussi <[EMAIL PROTECTED]>
Martin Hunt <[EMAIL PROTECTED]>
David Wilder <[EMAIL PROTECTED]>
---
Documentation/trace.txt | 297
include/linux/trace.h | 99
lib/Kconfig | 10 +
lib/Makefile
Trace - Provides tracing primitives
Tom Zanussi [EMAIL PROTECTED]
Martin Hunt [EMAIL PROTECTED]
David Wilder [EMAIL PROTECTED]
---
Documentation/trace.txt | 297
include/linux/trace.h | 99
lib/Kconfig | 10 +
lib/Makefile|2
On Thu, 13 Sep 2007 16:43:16 -0700 David Wilder wrote:
[it would be easier to review and make sense of the comments
if the patch were inline instead of attached]
Tom Zanussi [EMAIL PROTECTED]
Martin Hunt [EMAIL PROTECTED]
David Wilder [EMAIL PROTECTED]
Above needs to use Signed-off-by: if
58 matches
Mail list logo
