Re: ptrace vs /proc

[Pavel Machek]

Hi!

> >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.

Agreed signals should not be overloaded.

I helped with subterfugue (.sf.net), so I know about this
issues. Using signals is ugly. I'm not sure what to do with following
fork; I do not think we want to bloat kernel with that (and I believe
we have helper [CLONE_? flag?] that allows us to do that too). I still
think ptrace() should have its own syscall. Its very special thing.
								Pavel
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?