From: Christoph Hellwig <hch@infradead.org>
To: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@elte.hu>,
Masami Hiramatsu <mhiramat@redhat.com>,
Mel Gorman <mel@csn.ul.ie>, Randy Dunlap <rdunlap@xenotime.net>,
Arnaldo Carvalho de Melo <acme@infradead.org>,
Roland McGrath <roland@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Christoph Hellwig <hch@infradead.org>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
Oleg Nesterov <oleg@redhat.com>, Mark Wielaard <mjw@redhat.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Jim Keniston <jkenisto@linux.vnet.ibm.com>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
"Frank Ch. Eigler" <fche@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH v5 11/14] trace: uprobes trace_event interface
Date: Tue, 22 Jun 2010 02:34:28 -0400 [thread overview]
Message-ID: <20100622063428.GA15092@infradead.org> (raw)
In-Reply-To: <20100622041529.GA25989@linux.vnet.ibm.com>
On Tue, Jun 22, 2010 at 09:45:29AM +0530, Srikar Dronamraju wrote:
> As you see UPROBE_EVENT is gated on UPROBES. I think if UPROBES is
> enabled, then UPROBE_EVENT should be enabled. Esp with Christoph
> suggesting for module support to be removed, I think it becomes all the
> more reason for UPROBE_EVENT to be enabled by default. Otherwise there
> is no point in having uprobes code and having no enabled users.
> I was even looking at "select UPROBE_EVENT" on enabling UPROBES.
>
> Do you have any specific reason why UPROBE_EVENT should not be enabled
> by default?
default y generally is a big hammer. But given that it depends on
UPROBES it might be fine here. Then again the big question is why
we even bother with separate config options? At least in this form
UPROBES just is supported for UPROBE_EVENT. So it makes sense either
to remove the UPROBES option entirely, or at least make it invisible
to the user and let UPROBE_EVENT select it.
next prev parent reply other threads:[~2010-06-22 6:35 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-14 8:27 [PATCH v5 0/14] Uprobes v5 Srikar Dronamraju
2010-06-14 8:28 ` [PATCH v5 1/14] X86 instruction analysis: Move Macro W to insn.h Srikar Dronamraju
2010-06-14 17:39 ` Christoph Hellwig
2010-06-15 6:32 ` Srikar Dronamraju
2010-06-14 8:28 ` [PATCH v5 2/14] mm: Move replace_page to mm/memory.c Srikar Dronamraju
2010-06-14 17:44 ` Christoph Hellwig
2010-06-15 4:00 ` Srikar Dronamraju
2010-06-15 6:23 ` Christoph Hellwig
2010-06-14 8:28 ` [PATCH v5 3/14] User Space Breakpoint Assistance Layer Srikar Dronamraju
2010-06-14 17:40 ` Christoph Hellwig
2010-06-21 14:20 ` Steven Rostedt
2010-06-14 17:50 ` Christoph Hellwig
2010-06-15 11:27 ` Srikar Dronamraju
2010-06-21 13:59 ` Steven Rostedt
2010-06-22 5:44 ` Srikar Dronamraju
2010-06-14 8:28 ` [PATCH v5 4/14] x86 support for User space breakpoint assistance Srikar Dronamraju
2010-06-14 8:28 ` [PATCH v5 5/14] Slot allocation for execution out of line (XOL) Srikar Dronamraju
2010-06-14 17:52 ` Christoph Hellwig
2010-06-16 7:06 ` Srikar Dronamraju
2010-06-14 8:29 ` [PATCH v5 6/14] Uprobes Implementation Srikar Dronamraju
2010-06-14 14:27 ` Randy Dunlap
2010-06-15 11:30 ` Srikar Dronamraju
2010-06-14 8:29 ` [PATCH v5 7/14] x86 support for Uprobes Srikar Dronamraju
2010-06-14 17:54 ` Christoph Hellwig
2010-06-15 6:23 ` Srikar Dronamraju
2010-06-15 11:51 ` Oleg Nesterov
2010-06-15 12:15 ` Srikar Dronamraju
2010-06-15 13:15 ` Oleg Nesterov
2010-06-21 14:12 ` Steven Rostedt
2010-06-14 8:29 ` [PATCH v5 8/14] samples: Uprobes samples Srikar Dronamraju
2010-06-14 17:47 ` Christoph Hellwig
2010-06-14 8:29 ` [PATCH v5 9/14] Uprobes documentation Srikar Dronamraju
2010-06-14 8:29 ` [PATCH v5 10/14] trace: Common code for kprobes/uprobes traceevents Srikar Dronamraju
2010-06-15 4:13 ` Masami Hiramatsu
2010-06-21 14:18 ` Steven Rostedt
2010-06-22 5:46 ` Srikar Dronamraju
2010-06-14 8:30 ` [PATCH v5 11/14] trace: uprobes trace_event interface Srikar Dronamraju
2010-06-21 14:22 ` Steven Rostedt
2010-06-22 4:15 ` Srikar Dronamraju
2010-06-22 6:34 ` Christoph Hellwig [this message]
2010-06-14 8:30 ` [PATCH v5 12/14] perf: Dont adjust symbols on name lookup Srikar Dronamraju
2010-06-14 8:30 ` [PATCH v5 13/14] perf: Re-Add make_absolute_path Srikar Dronamraju
2010-06-14 8:30 ` [PATCH v5 14/14] perf: perf interface for uprobes Srikar Dronamraju
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100622063428.GA15092@infradead.org \
--to=hch@infradead.org \
--cc=acme@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=ananth@in.ibm.com \
--cc=fche@redhat.com \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=jkenisto@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mel@csn.ul.ie \
--cc=mhiramat@redhat.com \
--cc=mingo@elte.hu \
--cc=mjw@redhat.com \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rdunlap@xenotime.net \
--cc=rjw@sisk.pl \
--cc=roland@redhat.com \
--cc=rostedt@goodmis.org \
--cc=srikar@linux.vnet.ibm.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).