Re: linux-next: add utrace tree

[Johannes Stezenbach <js@sig21.net>]

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 
> scenario".
> 
> 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
debugging stuff.

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.


Johannes