Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756687Ab0AONio (ORCPT ); Fri, 15 Jan 2010 08:38:44 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756380Ab0AONin (ORCPT ); Fri, 15 Jan 2010 08:38:43 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49293 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750748Ab0AONim (ORCPT ); Fri, 15 Jan 2010 08:38:42 -0500 Date: Fri, 15 Jan 2010 08:38:25 -0500 From: "Frank Ch. Eigler" To: Peter Zijlstra Cc: Jim Keniston , Arnaldo Carvalho de Melo , Frederic Weisbecker , LKML , Mark Wielaard , utrace-devel Subject: Re: [RFC] [PATCH 4/7] Uprobes Implementation Message-ID: <20100115133825.GQ4822@redhat.com> References: <20100111122521.22050.3654.sendpatchset@srikar.in.ibm.com> <20100111122553.22050.46895.sendpatchset@srikar.in.ibm.com> <1263467394.4244.291.camel@laptop> <1263509380.4875.35.camel@localhost.localdomain> <1263546632.4244.352.camel@laptop> <1263548124.4244.358.camel@laptop> <20100115131037.GP4822@redhat.com> <1263561930.4244.417.camel@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1263561930.4244.417.camel@laptop> User-Agent: Mutt/1.4.2.2i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi - On Fri, Jan 15, 2010 at 02:25:30PM +0100, Peter Zijlstra wrote: > [...] > > utrace is not a form of punishment inflicted upon the undeserving. It > > is a service layer that uprobes et alii are built upon. You as a > > potential uprobes client need not also talk directly to it, if you > > wish to reimplement task-finder-like services some other way. > > [...] > But yes, I think that for most purposes utrace is a punishment, its way > too heavy, I mean, trap, generate a signal, catch the signal, that's > like an insane amount of code to jump through in order to get that trap. At the bottom, there will be an int3 in the userspace text page. There will be a trap taken, no matter what. Code must figure out whether this trap came from an in-kernel client such as uprobes, or whether it is to be passed through to a userspace debugger via ptrace (or the gdbstub). This part is unavoidable if you wish to be compatible. I'm not sure, but it sounds like the part you're complaining about is how utrace ultimately reports the trap to uprobes: i.e., utrace_get_signal()? Is that the "insane amount of code"? > Furthermore it requires stopping and resuming tasks and nonsense like > that, that's unwanted in many cases, just run stuff from the trap site > and you're done. I don't know what you mean exactly. A trap already stopped task. utrace merely allows various clients to inspect/manipulate the state of the task at that moment. It does not add any context switches or spurious stop/resumue operations. - FChE -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/