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
Hi -
On Mon, Jan 25, 2010 at 08:52:41AM -0800, Linus Torvalds wrote:
[...] 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. [...]
On Mon, 25 Jan 2010, Frank Ch. Eigler wrote:
Earlier, you said that you haven't followed utrace at all. Upon
what real information do you infer that it has been over-designed?
Upon the information that people are talking about magic new kernel
interfaces to do fancy things. And talking
On Mon, 25 Jan 2010, Linus Torvalds wrote:
So give me a populist argument that makes sense for tons of actual users,
not some f*cking here's a cool infrastructure that developers can do
random crazy out-of-tree crap with. Because I'm not interested in crazy
developers.
In other words,
On Mon, 2010-01-25 at 09:36 -0800, Linus Torvalds wrote:
Because I'm not interested in crazy
developers.
Linus
Uh oh, that's not good for us real-time folks.
http://lwn.net/Articles/357800/
And, according to Linus, the realtime people are crazy, so they can be
Uh oh, that's not good for us real-time folks.
http://lwn.net/Articles/357800/
And, according to Linus, the realtime people are crazy, so they can be
left to deal with the weird stuff.
I'd prefer the trees to be separate for testing purposes: it
doens't make much sense to
On Mon, 25 Jan 2010, Steven Rostedt wrote:
Uh oh, that's not good for us real-time folks.
http://lwn.net/Articles/357800/
And, according to Linus, the realtime people are crazy, so they can be
left to deal with the weird stuff.
The RT people have actually been pretty good at slipping
On Mon, 2010-01-25 at 10:12 -0800, Linus Torvalds wrote:
But on the whole, I think it's actually worked out pretty well for them. I
think the mainline kernel has improved in the process, but I also suspect
that _their_ RT patches have also improved thanks to having to make the
work more
On Mon, 25 Jan 2010, Steven Rostedt wrote:
On Mon, 2010-01-25 at 10:12 -0800, Linus Torvalds wrote:
But on the whole, I think it's actually worked out pretty well for them. I
think the mainline kernel has improved in the process, but I also suspect
that _their_ RT patches have also
* Thomas Gleixner t...@linutronix.de wrote:
On Mon, 25 Jan 2010, Steven Rostedt wrote:
On Mon, 2010-01-25 at 10:12 -0800, Linus Torvalds wrote:
But on the whole, I think it's actually worked out pretty well for them.
I think the mainline kernel has improved in the process, but I
On Mon, 25 Jan 2010, Mark Wielaard wrote:
And all these users have wishes to extend the current ptrace interface
mess. But nobody dares to extend ptrace in any direction because
fixing/cleaning up one of these use cases might break the others in
subtle and not so subtle ways. Which is why
Linus == Linus Torvalds torva...@linux-foundation.org writes:
Linus No. There is absolutely _no_ reason to believe that gdb et al would ever
Linus delete the ptrace interfaces anyway.
Yes, in GDB we approximately never delete anything.
Nevertheless, if the Linux kernel were to present a new
On Mon, 25 Jan 2010, Tom Tromey wrote:
There are definitely things we would like from such an API. Here's a
few I can think of immediately, there are probably others.
* Use an fd, not SIGCHLD+wait, to report inferior state changes to gdb.
Internally we're already using a self-pipe to
Let me add my two euro-cents to this discussion.
Mark Wielaard m...@redhat.com:
Unfortunately ptrace does all that magic already (badly). People don't
just use it for (s)tracing syscalls, but also for tracing signals, for
single step debugging and poking at memory, register state, for process
On Tue, 26 Jan 2010, Renzo Davoli wrote:
The solution is that everybody can code his/her optimized kernel/user
interface for tracing in his/her kernel module, i.e. utrace.
I don't think people understand. That is simply not a solution. That is
a PROBLEM. The thing you describe is an
15 matches
Mail list logo
