[PATCH] sh: remove stray markers

[PATCH] sh: remove stray markers

[Christoph Hellwig]

arch/sh has a couple of stray markers without any users introduced
in commit 3d58695edbfac785161bf282dc11fd42a483d6c9.  Remove them in
preparation of removing the markers in favour of the TRACE_EVENT
macro (and also because we don't keep dead code around).

Paul, are you okay putting this in via the tracing tree?  I'd like
to have all marker removals queued up there so we can kill it in one
go once 2.6.31 opens.


Signed-off-by: Christoph Hellwig <hch@lst.de>

Index: linux-2.6-tip/arch/sh/kernel/process_32.c
===================================================================
--- linux-2.6-tip.orig/arch/sh/kernel/process_32.c	2009-05-06 10:35:22.000000000 +0000
+++ linux-2.6-tip/arch/sh/kernel/process_32.c	2009-05-06 10:35:25.000000000 +0000
@@ -119,8 +119,6 @@
 	pid = do_fork(flags | CLONE_VM | CLONE_UNTRACED, 0,
 		      &regs, 0, NULL, NULL);
 
-	trace_mark(kernel_arch_kthread_create, "pid %d fn %p", pid, fn);
-
 	return pid;
 }
 
Index: linux-2.6-tip/arch/sh/kernel/process_64.c
===================================================================
--- linux-2.6-tip.orig/arch/sh/kernel/process_64.c	2009-05-06 10:35:22.000000000 +0000
+++ linux-2.6-tip/arch/sh/kernel/process_64.c	2009-05-06 10:35:36.000000000 +0000
@@ -323,7 +323,6 @@
 int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
 {
 	struct pt_regs regs;
-	int pid;
 
 	memset(&regs, 0, sizeof(regs));
 	regs.regs[2] = (unsigned long)arg;
@@ -333,12 +332,8 @@
 	regs.sr = (1 << 30);
 
 	/* Ok, create the new process.. */
-	pid = do_fork(flags | CLONE_VM | CLONE_UNTRACED, 0,
+	return do_fork(flags | CLONE_VM | CLONE_UNTRACED, 0,
 		      &regs, 0, NULL, NULL);
-
-	trace_mark(kernel_arch_kthread_create, "pid %d fn %p", pid, fn);
-
-	return pid;
 }
 
 /*
Index: linux-2.6-tip/arch/sh/kernel/sys_sh.c
===================================================================
--- linux-2.6-tip.orig/arch/sh/kernel/sys_sh.c	2009-05-06 10:35:22.000000000 +0000
+++ linux-2.6-tip/arch/sh/kernel/sys_sh.c	2009-05-06 10:35:41.000000000 +0000
@@ -79,8 +79,6 @@
 	version = call >> 16; /* hack for backward compatibility */
 	call &= 0xffff;
 
-	trace_mark(kernel_arch_ipc_call, "call %u first %d", call, first);
-
 	if (call <= SEMTIMEDOP)
 		switch (call) {
 		case SEMOP:
Index: linux-2.6-tip/arch/sh/mm/fault_32.c
===================================================================
--- linux-2.6-tip.orig/arch/sh/mm/fault_32.c	2009-05-06 10:35:22.000000000 +0000
+++ linux-2.6-tip/arch/sh/mm/fault_32.c	2009-05-06 10:35:59.000000000 +0000
@@ -249,9 +249,6 @@
 {
 	int ret = 0;
 
-	trace_mark(kernel_arch_trap_entry, "trap_id %d ip #p%ld",
-		   trap >> 5, instruction_pointer(regs));
-
 #ifdef CONFIG_KPROBES
 	if (!user_mode(regs)) {
 		preempt_disable();
@@ -327,6 +324,5 @@
 
 	ret = 0;
 out:
-	trace_mark(kernel_arch_trap_exit, MARK_NOARGS);
 	return ret;
 }

Re: [PATCH] sh: remove stray markers

[Ingo Molnar]

* Christoph Hellwig <hch@lst.de> wrote:

> arch/sh has a couple of stray markers without any users introduced 
> in commit 3d58695edbfac785161bf282dc11fd42a483d6c9.  Remove them 
> in preparation of removing the markers in favour of the 
> TRACE_EVENT macro (and also because we don't keep dead code 
> around).
> 
> Paul, are you okay putting this in via the tracing tree?  I'd like 
> to have all marker removals queued up there so we can kill it in 
> one go once 2.6.31 opens.

It's fine with me to have this included in the SH tree as well. The 
process.c files tend to be frequently modified in architectures so 
having overlap between tip/tracing and the SH tree could become 
awkward to Paul.

Also, if there's some current use of these markers then it's OK to 
not do this change right now but replace them with tracepoints in 
the v2.6.31 merge window, after both the SH and the tracing 
infrastructure changes are upstream.

	Ingo

Re: [PATCH] sh: remove stray markers

[Christoph Hellwig]

On Wed, May 06, 2009 at 01:07:35PM +0200, Ingo Molnar wrote:
> Also, if there's some current use of these markers then it's OK to 
> not do this change right now but replace them with tracepoints in 
> the v2.6.31 merge window, after both the SH and the tracing 
> infrastructure changes are upstream.

There's not user of these.  The two only uses sets of markers are
sputrace, and kvmtrace.  I've sent a patch for the first, and the
latter is work in progress.

Re: [PATCH] sh: remove stray markers

[Ingo Molnar]

* Christoph Hellwig <hch@lst.de> wrote:

> On Wed, May 06, 2009 at 01:07:35PM +0200, Ingo Molnar wrote:
> > Also, if there's some current use of these markers then it's OK 
> > to not do this change right now but replace them with 
> > tracepoints in the v2.6.31 merge window, after both the SH and 
> > the tracing infrastructure changes are upstream.
> 
> There's not user of these. [...]

I'll defer to Paul to decide whether SH needs those markers. If he 
added them to ease his own debugging (via whatever external 
approach), then that's an OK goal and we can handle this all 
politely without destroying functionality, in the next merge window.

	Ingo

Re: [PATCH] sh: remove stray markers

[Paul Mundt]

On Wed, May 06, 2009 at 01:15:49PM +0200, Ingo Molnar wrote:
> 
> * Christoph Hellwig <hch@lst.de> wrote:
> 
> > On Wed, May 06, 2009 at 01:07:35PM +0200, Ingo Molnar wrote:
> > > Also, if there's some current use of these markers then it's OK 
> > > to not do this change right now but replace them with 
> > > tracepoints in the v2.6.31 merge window, after both the SH and 
> > > the tracing infrastructure changes are upstream.
> > 
> > There's not user of these. [...]
> 
> I'll defer to Paul to decide whether SH needs those markers. If he 
> added them to ease his own debugging (via whatever external 
> approach), then that's an OK goal and we can handle this all 
> politely without destroying functionality, in the next merge window.
> 
They were primarily added to aid some downstream folks that were just
adding these on their own and generally not paying attention to where the
markers were being placed on subsequent merges. I don't feel too strongly
one way or the other, but as they have proven to be useful for some
people, I would rather transition over to tracepoints during the merge
window than kill them off prematurely.

Re: [PATCH] sh: remove stray markers

[Ingo Molnar]

* Paul Mundt <lethal@linux-sh.org> wrote:

> On Wed, May 06, 2009 at 01:15:49PM +0200, Ingo Molnar wrote:
> > 
> > * Christoph Hellwig <hch@lst.de> wrote:
> > 
> > > On Wed, May 06, 2009 at 01:07:35PM +0200, Ingo Molnar wrote:
> > > > Also, if there's some current use of these markers then it's OK 
> > > > to not do this change right now but replace them with 
> > > > tracepoints in the v2.6.31 merge window, after both the SH and 
> > > > the tracing infrastructure changes are upstream.
> > > 
> > > There's not user of these. [...]
> > 
> > I'll defer to Paul to decide whether SH needs those markers. If he 
> > added them to ease his own debugging (via whatever external 
> > approach), then that's an OK goal and we can handle this all 
> > politely without destroying functionality, in the next merge window.
> 
> They were primarily added to aid some downstream folks that were 
> just adding these on their own and generally not paying attention 
> to where the markers were being placed on subsequent merges. I 
> don't feel too strongly one way or the other, but as they have 
> proven to be useful for some people, I would rather transition 
> over to tracepoints during the merge window than kill them off 
> prematurely.

fair enough!

	Ingo