Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753690Ab0AYVHT (ORCPT ); Mon, 25 Jan 2010 16:07:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753676Ab0AYVHO (ORCPT ); Mon, 25 Jan 2010 16:07:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59861 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753613Ab0AYVHL (ORCPT ); Mon, 25 Jan 2010 16:07:11 -0500 From: Tom Tromey To: Linus Torvalds Cc: Kyle Moffett , "Frank Ch. Eigler" , Oleg Nesterov , Andrew Morton , Stephen Rothwell , Peter Zijlstra , Peter Zijlstra , Fr??d??ric Weisbecker , LKML , Steven Rostedt , Arnaldo Carvalho de Melo , linux-next@vger.kernel.org, "H. Peter Anvin" , utrace-devel@redhat.com, Thomas Gleixner Subject: Re: linux-next: add utrace tree References: <20100121013822.28781960.sfr@canb.auug.org.au> <20100122005147.GD22003@redhat.com> <20100121170541.7425ff10.akpm@linux-foundation.org> <20100122182827.GA13185@redhat.com> <20100122200129.GG22003@redhat.com> <20100122221348.GA4263@redhat.com> Reply-To: tromey@redhat.com X-Attribution: Tom Date: Mon, 25 Jan 2010 14:05:54 -0700 In-Reply-To: (Linus Torvalds's message of "Sat, 23 Jan 2010 21:04:56 -0800 (PST)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1384 Lines: 32 >>>>> "Linus" == Linus Torvalds writes: Linus> No. There is absolutely _no_ reason to believe that gdb et al would ever Linus> delete the ptrace interfaces anyway. Yes, in GDB we approximately never delete anything. Nevertheless, if the Linux kernel were to present a new user-space API, and if it had an advantage over ptrace, then we would port GDB to use it. There are other platforms where, IIRC, we now use some /proc thing instead of ptrace. There are definitely things we would like from such an API. Here's a few I can think of immediately, there are probably others. * Use an fd, not SIGCHLD+wait, to report inferior state changes to gdb. Internally we're already using a self-pipe to integrate this into gdb's main loop. Relatedly, don't mess with the inferior's parentage. * Support "displaced stepping" in the kernel; I think this would improve performance when debugging in non-stop mode. * Support some kind of breakpoint expression in the kernel; this would improve performance of conditional breakpoints. Perhaps the existing gdb agent expressions could be used. Tom -- 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/