|| ||Linus Torvalds <torvalds-AT-linux-foundation.org> |
|| ||Kyle Moffett <kyle-AT-moffetthome.net> |
|| ||Re: linux-next: add utrace tree |
|| ||Mon, 25 Jan 2010 08:52:41 -0800 (PST)|
|| ||Stephen Rothwell <sfr-AT-canb.auug.org.au>, tytso-AT-mit.edu,
Peter Zijlstra <a.p.zijlstra-AT-chello.nl>,
Peter Zijlstra <peterz-AT-infradead.org>,
Fr??d??ric Weisbecker <fweisbec-AT-gmail.com>,
Oleg Nesterov <oleg-AT-redhat.com>, Steven Rostedt <rostedt-AT-goodmis.org>,
Arnaldo Carvalho de Melo <acme-AT-redhat.com>,
"Frank Ch. Eigler" <fche-AT-redhat.com>, linux-next-AT-vger.kernel.org,
Thomas Gleixner <tglx-AT-linutronix.de>, "H. Peter Anvin" <hpa-AT-zytor.com>,
|| ||Article, Thread
On Sun, 24 Jan 2010, Kyle Moffett wrote:
> The point that's being missed is that there is a chicken-and-egg
> problem here. The "chicken" is a replacement or extension to the
> debugger interface that would make it possible for me to do things
> like GDB a process while it's being strace'd or vice versa. The "egg"
> is the "utrace" bits, an unstable but somewhat arch-generic ABI that
> abstracts out ptrace() to make it possible to stack both in-kernel and
> userspace debuggers/tracers/etc and have multiple simultaneous users.
Quite frankly, as far as I'm concerned, I'd be a whole lot more interested
in utrace if it's _only_ stated (and implied) goal was to do exactly this.
The thing I object to is the whole "dessert topping _and_ floor wax"
thing, with kernel interfaces for random other users.
If somebody extended ptrace in good ways, that's a totally different
thing. But I think utrace has been over-designed, possibly as a result of
others coming in and saying "hey, I'd like to use that too for xyz".
"Do one thing, and do it well". I'd not mind somebody improving ptrace
(including extending its semantics - I do agree that the whole SIGSTOP
thing makes it hard to have multiple debuggers).
That said, I also suspect that people should still look seriously at
simply just improving ptrace. For example, I suspect that the biggest
problem with ptrace is really just the signalling, and that creating a new
extension for JUST THAT, and then having a model where you can choose - at
PTRACE_ATTACH time - how to wait for events would be a good thing.
But as long as it is "I want to solve all problems", I'm not very
Maybe somebody would be interested in trying to take the utrace
improvements, and scaling down what they promise, and ignoring all input
except for "I want to strace and gdb at the same time".
So stop the crazy "new kernel interfaces" crap. Stop the crazy "maybe we
can use it for ftrace and generic user event tracing too". Stop the crazy.
to post comments)