Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754182Ab0AYQyY (ORCPT ); Mon, 25 Jan 2010 11:54:24 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754151Ab0AYQyT (ORCPT ); Mon, 25 Jan 2010 11:54:19 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:54738 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754121Ab0AYQyQ (ORCPT ); Mon, 25 Jan 2010 11:54:16 -0500 Date: Mon, 25 Jan 2010 08:52:41 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Kyle Moffett cc: tytso@mit.edu, "Frank Ch. Eigler" , Ingo Molnar , 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 In-Reply-To: Message-ID: References: <20100122200129.GG22003@redhat.com> <20100122221348.GA4263@redhat.com> <20100123112333.GA15455@elte.hu> <20100123114729.GA7828@redhat.com> <20100123194820.GM21263@thunk.org> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) 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: 2267 Lines: 48 On Sun, 24 Jan 2010, Kyle Moffett wrote: > > The point that's being missed is that there is a chicken-and-egg > problem here. The "chicken" is a replacement or extension to the > debugger interface that would make it possible for me to do things > like GDB a process while it's being strace'd or vice versa. The "egg" > is the "utrace" bits, an unstable but somewhat arch-generic ABI that > abstracts out ptrace() to make it possible to stack both in-kernel and > userspace debuggers/tracers/etc and have multiple simultaneous users. Quite frankly, as far as I'm concerned, I'd be a whole lot more interested in utrace if it's _only_ stated (and implied) goal was to do exactly this. The thing I object to is the whole "dessert topping _and_ floor wax" thing, with kernel interfaces for random other users. If somebody extended ptrace in good ways, that's a totally different thing. But I think utrace has been over-designed, possibly as a result of others coming in and saying "hey, I'd like to use that too for xyz". "Do one thing, and do it well". I'd not mind somebody improving ptrace (including extending its semantics - I do agree that the whole SIGSTOP thing makes it hard to have multiple debuggers). That said, I also suspect that people should still look seriously at simply just improving ptrace. For example, I suspect that the biggest problem with ptrace is really just the signalling, and that creating a new extension for JUST THAT, and then having a model where you can choose - at PTRACE_ATTACH time - how to wait for events would be a good thing. But as long as it is "I want to solve all problems", I'm not very impressed. Maybe somebody would be interested in trying to take the utrace improvements, and scaling down what they promise, and ignoring all input except for "I want to strace and gdb at the same time". So stop the crazy "new kernel interfaces" crap. Stop the crazy "maybe we can use it for ftrace and generic user event tracing too". Stop the crazy. Linus -- 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/