From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: linux-next: add utrace tree Date: Tue, 26 Jan 2010 11:34:31 -0500 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 Return-path: 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 Content-Disposition: inline In-Reply-To: Sender: linux-next-owner@vger.kernel.org List-ID: 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 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.