Re: linux-next: add utrace tree
From: Johannes Stezenbach
Date: Tue Jan 26 2010 - 11:09:13 EST
On Mon, Jan 25, 2010 at 04:07:21PM -0800, Linus Torvalds wrote:
> On Tue, 26 Jan 2010, Renzo Davoli wrote:
> > The solution is that everybody can code his/her optimized kernel/user
> > interface for tracing in his/her kernel module, i.e. utrace.
> I don't think people understand. That is simply not a "solution". That is
> a PROBLEM. The thing you describe is an absolute disaster. Which is
> exactly why I rant against it.
> The last thing we want to have is "here, take this, and make your own
> kernel module mess around it optimized for your particular crazy
> But every SINGLE post in this thread that has argued for utrace has argued
> exactly this way.
I haven't followed much of the utrace discussions, but my impression was
that utrace primarily is a cleanup effort, replacing "don't change it,
you might break it" code with a clean, well defined (and even documented)
implementation. To make it easier for people not familiar
with the low-level architecture details to experiment with
Two points to consider:
1. If you'd merge utrace + ptrace-on-utrace, but never anything else
which uses the utrace API, wouldn't it still be an improvement?
2. A well defined utrace API makes debugging code more hackable, thus more
likely that someone might come up with a brilliant killer debug
feature in the future. (This might sound lame, but there are already
a few people doing crazy things with utrace while I'm not aware
that people have done such experiments based on the current ptrace impl.)
BTW, the ptrace improvements discussed elsewhere in this thread
(like using an fd intead of signals/wait) are orthogonal
to utrace, no? IMHO it's a seperate discussion.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/