Roland McGrath wrote:
Sorry to be blunt, Chris. But I think you're headed down a useless rat hole.
I agree that the usage of /proc you've described is a bad interface.
I am slightly mystified as to how that came to be what you settled on.
At the time Andrew Cagney and I decided to go
On Tue, Jul 01, 2008 at 03:28:04PM -0400, Chris Moller wrote:
K.Prasad wrote:
Hi All,
Sorry if I have missed out something I need to know before I
respond to this email. But the trace infrastructure (lib/trace.c)
already provides such a facility which more features such as per-cpu
K.Prasad wrote:
On Tue, Jul 01, 2008 at 03:28:04PM -0400, Chris Moller wrote:
K.Prasad wrote:
Hi All,
Sorry if I have missed out something I need to know before I
respond to this email. But the trace infrastructure (lib/trace.c)
already provides such a facility which more
So now we have four possibles: extending ptrace, a new
ptrace-replacement syscall, a systemtap-based thing, and, now, ntrace.
Things are diverging rather than converging.
A couple of comments concerning the /proc entry fd method utracer uses
and than some people have expressed a preference
Chris Moller [EMAIL PROTECTED] writes:
[...]
and than some people have expressed a preference for: The first is
that it's clumsy. When the utracer module loads, it creates a /proc
pseudo-directory /proc/utrace and then a pseudo-file
/proc/utrace/control. [...]
FWIW, it'd make more sense
Hi,
On Wed, Jun 25, 2008 at 8:39 PM, David Miller [EMAIL PROTECTED] wrote:
From: Chris Moller [EMAIL PROTECTED]
Date: Wed, 25 Jun 2008 19:11:57 -0400
I agree in principal, but there are years and years of old cruft in gdb
too and I'm not altogether sure that separating the experience from
On Tue, 2008-06-24 at 22:49 -0400, Chris Moller wrote:
Comments, up to and including What the hell are you smoking? welcome.
I'd rather phrase this as what are we not getting out of ptrace that we
really want. Answering that will frame how we go about getting it. (I
admit to not having looked
On Wed, Jun 25, 2008 at 12:30:03PM -0400, Chris Moller wrote:
Extending ptrace seems like a sad idea. If Linux is going to grow a
new userspace-accessible debug interface, can't it go in /proc or
something?
Actually, that's exactly what utracer does. It's a module that creates
an
Phil Muldoon wrote:
Chris Moller wrote:
Due to a complete lack of interest, I'm shelving utracer. May it
collect dust in peace.
I was (and still am) interested in it from a direct api point of view.
As a an end-tool not so much.
Systemtap is cool, and, based on tinkering with it for
Daniel Jacobowitz wrote:
On Wed, Jun 25, 2008 at 12:30:03PM -0400, Chris Moller wrote:
Extending ptrace seems like a sad idea. If Linux is going to grow a
new userspace-accessible debug interface, can't it go in /proc or
something?
Actually, that's exactly what utracer does.
On Wed, Jun 25, 2008 at 04:11:50PM -0400, Chris Moller wrote:
The main reason I'm moving away from this approach is that the overhead
of read()/write()/ioctl() to/from a /proc pseudo-entry is a lot higher
than a simple syscall. It's mostly a performance thing, but there's also
less code
From: Daniel Jacobowitz [EMAIL PROTECTED]
Date: Wed, 25 Jun 2008 11:38:25 -0400
The single biggest pain in GDB's process management is dealing with
signals, especially the ways that ptrace interferes with normal
operation.
Because of this, and other similar examples, I believe the only
way to
David Miller wrote:
From: Daniel Jacobowitz [EMAIL PROTECTED]
Date: Wed, 25 Jun 2008 11:38:25 -0400
The single biggest pain in GDB's process management is dealing with
signals, especially the ways that ptrace interferes with normal
operation.
Because of this, and other similar
13 matches
Mail list logo
