Messages in this thread | | | Date | Mon, 25 Jan 2010 12:42:22 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: 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
| |