Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754701Ab0AZQfT (ORCPT ); Tue, 26 Jan 2010 11:35:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754088Ab0AZQfS (ORCPT ); Tue, 26 Jan 2010 11:35:18 -0500 Received: from bombadil.infradead.org ([18.85.46.34]:34409 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753949Ab0AZQfQ (ORCPT ); Tue, 26 Jan 2010 11:35:16 -0500 Date: Tue, 26 Jan 2010 11:34:31 -0500 From: Christoph Hellwig To: Linus Torvalds Cc: Johannes Stezenbach , Renzo Davoli , Mark Wielaard , Stephen Rothwell , Kyle Moffett , tytso@mit.edu, 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, Thomas Gleixner Subject: Re: linux-next: add utrace tree Message-ID: <20100126163431.GA1658@infradead.org> References: <20100125170254.GB22862@redhat.com> <1264451453.3028.59.camel@springer.wildebeest.org> <20100126000237.GA15936@cs.unibo.it> <20100126160811.GA3242@sig21.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1787 Lines: 31 On Tue, Jan 26, 2010 at 08:28:15AM -0800, Linus Torvalds wrote: > I already said earlier that I'd be perfectly happy to merge utrace code, > as long as it was clear that I'm not merging a platform for crazy work. > IOW, the end result might be merging 99% of the code, but I want to set > peoples _expectations_ right. I'm not at all interested in merging stuff > that has various exported helper functions for people doing random things, > but I could happily merge stuff that cleans up internal implementation. > Clean code makes things easier to improve, and maybe utrace cleans thigns > up. But defining new API's makes me very worried, and quite frankly, the > last thing I ever want to see is a new interface that out-of-tree modules > starr using for random hacking. To be fair Roland and Oleg did a lot of work on improving ptrace support that was an offsprint of utrace. It would be great if the reamaining architectures would catch up on beeing converted to it and getting rid of the existing hairy arch ptrace code as much as possible. I'm still not really set on utrace either, but the in-kernel gdbstub Frank has started could be a real killer if it ever gets done up to a fully usable state. If it really requires all the utrace abstractions that seem a bit overdone I'm not sure. Might be a better idea to try to get uprobes and the gdbstub in without it and see how much of the abstraction will be needed anyway as a fallout, just without exporting them to modules and thus actually making them published APIs. -- 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/