lkml.org 
[lkml]   [2010]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: linux-next: add utrace tree


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


\
 
 \ /
  Last update: 2010-01-25 21:45    [W:0.136 / U:17.648 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site