[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]


We don't have any particular plans to extend the ptrace interface.  
I strongly doubt we would even try to do anything like that until the
utrace-based ptrace interface is merged into Linux and the old ptrace
implementation gone.

In general, we are not looking for extensions to the ptrace interface.
It is an ugly hairball already and we are more interested in having 
the utrace API layer available inside the kernel and then embarking on
new and sane userland interfaces instead of shoehorning more into ptrace.

That said, some particular kinds of simple enhancements to ptrace are
really quite trivial to implement in the new utrace-based implementation.
The particular area you suggest is one of these.

What I would expect is not new variants of the one-shot interface like
PTRACE_SYSCALL.  Rather, I would envision new PTRACE_O_* options to enable
syscall entry and exit tracing analogous to the PTRACE_EVENT_* events you
can now enable.  This means that you make one PTRACE_SETOPTIONS call to
enable the set of events you want, and then use plain PTRACE_CONT (or

If you really want exactly the one-shot behavior instead, then we could
consider that.  But, like I said, we are not looking to add much in the
way of new wrinkles to the dismal ptrace userland interface.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]