Re: ptrace vs /proc

[daw@mozart.cs.berkeley.edu (David Wagner)]

Pavel Machek  wrote:
>I believe such proc interface is wrong thing to do. ptrace() is really
>very *very* special thing, and you don't want it hidden in some kind
>of /proc magic.

Five years ago I believed all that mattered was the functionality:
whether it was exposed via ptrace() and signals or via /proc and ioctls
was irrelevant.  Since then, having spent a lot of time using both Linux
ptrace() and Solaris /proc, I've learned that there is a huge difference
between the two.  The Solaris implementation, via /proc, is very clean.
The Linux implementation, via ptrace(), is icky.

For example, ptrace() uses signals as part of its interface; this
is a gross kludgy hack, and it breaks various things.  For instance,
overloading the meaning of signals causes wait4() to break in the traced
process, and you have to do all sorts of workarounds in the tracer
to make tracing transparent.  Go read the source code to strace(1).
I think if you spend the time to understand it all, you'll agree with
me that it is sadly hairy stuff.

The Solaris /proc implementation, in contrast, was much cleaner,
in my experience.  I suspect this is partially because the Solaris
implementation was more carefully thought-through, but also the interface
helped: by not overloading the meaning of signals, the Solaris /proc
interface avoids changing the semantics of signal-related functionality
in the traced process, and this makes for cleaner code.

Solaris /proc also had other nice features, like the ability to follow
fork() automatically and so on.  (Check out what strace has to do with
ptrace(): it actually does binary code-rewriting of the traced process
on the fly to work around lack of functionality in ptrace().)  Many of
these features, of course, were orthogonal to whether the process tracing
was implemented via ptrace() and signals or /proc and ioctls.