Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753252Ab0AYE7Z (ORCPT ); Sun, 24 Jan 2010 23:59:25 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752273Ab0AYE7U (ORCPT ); Sun, 24 Jan 2010 23:59:20 -0500 Received: from e31.co.us.ibm.com ([32.97.110.149]:47466 "EHLO e31.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752031Ab0AYE7T (ORCPT ); Sun, 24 Jan 2010 23:59:19 -0500 Date: Mon, 25 Jan 2010 10:29:08 +0530 From: Ananth N Mavinakayanahalli To: Ingo Molnar Cc: Kyle Moffett , Stephen Rothwell , Peter Zijlstra , Peter Zijlstra , Fr??d??ric Weisbecker , Oleg Nesterov , Steven Rostedt , LKML , Arnaldo Carvalho de Melo , "Frank Ch. Eigler" , linux-next@vger.kernel.org, "H. Peter Anvin" , utrace-devel@redhat.com, Linus Torvalds , Thomas Gleixner Subject: Re: linux-next: add utrace tree Message-ID: <20100125045908.GB4895@in.ibm.com> Reply-To: ananth@in.ibm.com References: <20100121170541.7425ff10.akpm@linux-foundation.org> <20100122182827.GA13185@redhat.com> <20100122200129.GG22003@redhat.com> <20100122221348.GA4263@redhat.com> <20100123112333.GA15455@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100123112333.GA15455@elte.hu> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2462 Lines: 51 On Sat, Jan 23, 2010 at 12:23:33PM +0100, Ingo Molnar wrote: > > * Kyle Moffett wrote: > > > On Fri, Jan 22, 2010 at 19:22, Linus Torvalds > > wrote: ... > In that sense it might be better to fix/enhance ptrace, if there's interest. > I've written a handful of ptrace extensions in the past (none of them went > upstream tho), it can be done in a useful manner and the code is pretty > hackable. There are basic problems left to be solved: for example why is there > still no 'memory block copy' call, why are we _still_ limited to one word per > system call PTRACE_PEEK* memory copies? It's ridiculous. SparcLinux has > PTRACE_WRITE*/READ* support that implements this, but none of the other > architectures have it so it's essentially unused. > > Or another possible direction would be to extend the perf events syscall with > interception capabilities. It's far more performant at extracting application > state without scheduling than any ptrace method - and interception/injection > would be a natural next step - if there's interest. This certainly is now a chicken and egg problem. Everybody agrees that Linux needs something better than ptrace; legacy ptrace will continue to live, so will utilities written to it (strace, etc). But should that limit what Linux can offer? What's the way out? - Enhance ptrace: At least one ptrace maintainer (Roland) had publically stated he doesn't prefer enhancing legacy ptrace -- that its already a beast to maintain, and adding more complexity to it does it no good. - Extend perf; would perf then use utrace underneath? Or would one have to redo some of what utrace already does for thread level control? - Give utrace a syscall and make it the primary way for users to interact with the layer. There are benefits to this if there is agreement on the utrace layer itself, maybe with less fexibility than what it currently offers? If yes, what should it look like? Any new debug facility will have to incorporate some or most learnings from what utrace tried to address. It would be sad to just dump utrace and redo everything from scratch or band-aid existing interfaces. Ananth -- 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/