[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100126163431.GA1658@infradead.org>
Date: Tue, 26 Jan 2010 11:34:31 -0500
From: Christoph Hellwig <hch@...radead.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Johannes Stezenbach <js@...21.net>,
Renzo Davoli <renzo@...unibo.it>,
Mark Wielaard <mjw@...hat.com>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Kyle Moffett <kyle@...fetthome.net>, tytso@....edu,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Peter Zijlstra <peterz@...radead.org>,
Fr??d??ric Weisbecker <fweisbec@...il.com>,
Oleg Nesterov <oleg@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>,
LKML <linux-kernel@...r.kernel.org>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
"Frank Ch. Eigler" <fche@...hat.com>, linux-next@...r.kernel.org,
"H. Peter Anvin" <hpa@...or.com>, utrace-devel@...hat.com,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: linux-next: add utrace tree
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists