Re: linux-next: add utrace tree

Linus Torvalds
2010-01-25T20:43:18Z

On Mon, 25 Jan 2010, Mark Wielaard wrote:
>
> And all these users have wishes to extend the current ptrace interface
> mess. But nobody dares to extend ptrace in any direction because
> fixing/cleaning up one of these use cases might break the others in
> subtle and not so subtle ways. Which is why the utrace series of patches
> is cleaning up all this stuff first.

I call bullshit.

You can clean up ptrace without introducing odd new interfaces and trying
to sell it as some revolutionary new kernel interface that can do
anything.

I also call bullshit on the "ptrace() is so horribly nasty" argument. Yes,
I've seen the code that uses ptrace in user space, and yes, it's nasty,
but it's invariably _not_ nasty so much because ptrace itself is nasty,
but because it's full of #ifdef so-and-so-os/so-and-so-arch, and the code
is never cleaned up.

There are a couple of obvious cases of ptrace being uglier-than-it-needs-
to-be. Like the traditional ptrace read/write interface being purely "word
at a time", and that clearly is not pretty. Several architectures already
do "copy range" kind of versions on it, though, so that's just a detail,
and if anybody wanted to clean it up, they could have.

The more fundamental problem is the use of signals (while at the same time
wanting to _trap_ non-ptrace signals), without any model for a "connection
state", which is why you can have only one tracer. But again, that's
largely a user interface issue, and apparently utrace does _nothing_ for
that problem at all.

So I do agree that ptrace is not a great interface. However: repeating
that statement over and over in _no_ way excuses some totally unrelated
code that doesn't have anything what-so-ever to do with the actual
problems of ptrace.

Linus