On 01/27/2010 01:05 PM, Ananth N Mavinakayanahalli wrote:
We don't need to write one. I don't know how easy it is to make the kvm
emulator less kvm-centric (vcpus, kvm_context, etc). Avi?
It's a lot of mindless work but not too difficult; replacing hardcoded
accessors with function pointer
On Mon, 8 Feb 2010 07:54:25 +0100
Pavel Machek wrote:
> > No, it has nothing to do with ring. It has to do with modifying
> > code that another CPU could be executing at the same time, and with
> > modifying code on the same processor through another virtual alias
> > (they are different issues.
On 02/07/2010 10:54 PM, Pavel Machek wrote:
No, it has nothing to do with ring. It has to do with modifying code
that another CPU could be executing at the same time, and with modifying
code on the same processor through another virtual alias (they are
different issues.) The same issues apply
Hi!
> >>> Right, so you're going to love uprobes, which does exactly that. The
> >>> current proposal is overwriting the target instruction with an INT3 and
> >>> injecting an extra vma into the target process's address space
> >>> containing the original instruction(s) and possible jumps back to
Ingo Molnar wrote:
>
> * Ananth N Mavinakayanahalli wrote:
>
>> On Thu, Jan 28, 2010 at 09:55:02AM +0100, Ingo Molnar wrote:
>>
>> ...
>>
>>> Lets compare the two cases via a drawing. Your current uprobes submission
>>> does:
>>>
>>> [kernel] do probe thing single-step trap
>>>
On Sat, 30 Jan 2010, Steven Rostedt wrote:
>
> The kernel is limited to what instructions it can perform, no floating
> point for example (of course there are some exceptions).
Actually, the reason the kernel is limited to not performing floating
point instructions is that teh kernel doesn't o
On Fri, 2010-01-29 at 08:42 +0100, Ingo Molnar wrote:
> * Ananth N Mavinakayanahalli wrote:
>
> > On Thu, Jan 28, 2010 at 09:55:02AM +0100, Ingo Molnar wrote:
> >
> > ...
> >
> > > Lets compare the two cases via a drawing. Your current uprobes submission
> > > does:
> > >
> > > [kernel]
Ingo Molnar writes:
> [...] So, to sum it up: utrace XOL, which is rather complex already,
> needs even more complexity (which is not yet implemented) than the
> much simpler common-case emulator approach i outlined, just to break
> even with the performance of the much simpler approach. [...]
I
* Ananth N Mavinakayanahalli wrote:
> On Fri, Jan 29, 2010 at 10:11:16AM +0100, Ingo Molnar wrote:
> >
> > * Ananth N Mavinakayanahalli wrote:
> >
> > > On Fri, Jan 29, 2010 at 08:39:07AM +0100, Ingo Molnar wrote:
> > >
> > > ...
> > >
> > > > When we merged kprobes ~10 years ago we made th
On Fri, Jan 29, 2010 at 10:11:16AM +0100, Ingo Molnar wrote:
>
> * Ananth N Mavinakayanahalli wrote:
>
> > On Fri, Jan 29, 2010 at 08:39:07AM +0100, Ingo Molnar wrote:
> >
> > ...
> >
> > > When we merged kprobes ~10 years ago we made the (rather bad) mistake of
> > > merging a raw, opaque fa
* Ananth N Mavinakayanahalli wrote:
> On Fri, Jan 29, 2010 at 01:22:40PM +0530, Ananth N Mavinakayanahalli wrote:
> > On Fri, Jan 29, 2010 at 08:39:07AM +0100, Ingo Molnar wrote:
> >
> > ...
> >
> > > When we merged kprobes ~10 years ago we made the (rather bad) mistake of
> > > merging a raw
* Ananth N Mavinakayanahalli wrote:
> On Fri, Jan 29, 2010 at 08:39:07AM +0100, Ingo Molnar wrote:
>
> ...
>
> > When we merged kprobes ~10 years ago we made the (rather bad) mistake of
> > merging a raw, opaque facility and leaving 'the rest' up to some other
> > entity.
> > IBM kprobes ha
On Fri, Jan 29, 2010 at 01:22:40PM +0530, Ananth N Mavinakayanahalli wrote:
> On Fri, Jan 29, 2010 at 08:39:07AM +0100, Ingo Molnar wrote:
>
> ...
>
> > When we merged kprobes ~10 years ago we made the (rather bad) mistake of
> > merging a raw, opaque facility and leaving 'the rest' up to some o
On Fri, Jan 29, 2010 at 08:39:07AM +0100, Ingo Molnar wrote:
...
> When we merged kprobes ~10 years ago we made the (rather bad) mistake of
> merging a raw, opaque facility and leaving 'the rest' up to some other
> entity.
> IBM kprobes hackers vanished the day the original kprobes code went u
* Ananth N Mavinakayanahalli wrote:
> On Thu, Jan 28, 2010 at 09:55:02AM +0100, Ingo Molnar wrote:
>
> ...
>
> > Lets compare the two cases via a drawing. Your current uprobes submission
> > does:
> >
> > [kernel] do probe thing single-step trap
> >^|
* Jim Keniston wrote:
> > > As previously discussed, boosting would also get rid of the single-step
> > > trap for most instructions.
> >
> > Boosting is not in the uprobes patch-set you submitted. Even with it
> > present it wont get rid of the initial INT3. So basically _best-case_
> > (wi
On Thu, Jan 28, 2010 at 09:55:02AM +0100, Ingo Molnar wrote:
...
> Lets compare the two cases via a drawing. Your current uprobes submission
> does:
>
> [kernel] do probe thing single-step trap
>^| ^ |
>|v |
On Thu, 2010-01-28 at 09:55 +0100, Ingo Molnar wrote:
> * Jim Keniston wrote:
>
> > On Wed, 2010-01-27 at 09:54 +0100, Ingo Molnar wrote:
> > ...
> >
> > Yes, emulating "push %ebp" would buy us a lot of coverage for a lot of apps
> > on x86 (but see below**). [...]
>
...
>
> > [...] Even the
On Fri, 29 Jan 2010, Benjamin Herrenschmidt wrote:
>
> like returning a fd to poll() on ? :-)
Well, there's the possibility of async polling (rather than the
synchronous wait that ptrace forces now), but there are other advantages
to having a "connection" model - like not having to look up th
On Mon, 2010-01-25 at 08:52 -0800, Linus Torvalds wrote:
>
> 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 fo
* Jim Keniston wrote:
> On Wed, 2010-01-27 at 09:54 +0100, Ingo Molnar wrote:
> ...
> > I think the best solution for user probes (by far) is to use a simplified
> > in-kernel instruction emulator for the few common probes instruction.
> > (Kprobes
> > already partially decodes x86 instructio
On Wed, 2010-01-27 at 09:54 +0100, Ingo Molnar wrote:
...
> I think the best solution for user probes (by far) is to use a simplified
> in-kernel instruction emulator for the few common probes instruction.
> (Kprobes
> already partially decodes x86 instructions to make it safe to apply
> accele
On 01/27/2010 02:43 AM, Linus Torvalds wrote:
>
>
> On Wed, 27 Jan 2010, Peter Zijlstra wrote:
>>
>> Right, so you're going to love uprobes, which does exactly that. The
>> current proposal is overwriting the target instruction with an INT3 and
>> injecting an extra vma into the target process's
On Wed, 2010-01-27 at 09:42 -0800, H. Peter Anvin wrote:
> On 01/27/2010 05:59 AM, Steven Rostedt wrote:
> > I think the issue was that ring 0 was never meant to do that, where as,
> > ring 3 does it all the time. Doesn't the dynamic library modify its
> > text?
> >
>
> No, it has nothing to do
On 01/27/2010 05:59 AM, Steven Rostedt wrote:
> [ Added Arjan ]
>
> On Wed, 2010-01-27 at 02:43 -0800, Linus Torvalds wrote:
>>
>> On Wed, 27 Jan 2010, Peter Zijlstra wrote:
>>>
>>> Right, so you're going to love uprobes, which does exactly that. The
>>> current proposal is overwriting the target
On Wed, Jan 27, 2010 at 03:04:58AM -0800, Linus Torvalds wrote:
>
>
> On Wed, 27 Jan 2010, Peter Zijlstra wrote:
> >
> > Right, so there's two aspects:
> >
> > 1) concurrency when inserting the probe
>
> That's the one I worried about. Stopping all threads will fix it,
> obviously at a disas
[ Added Arjan ]
On Wed, 2010-01-27 at 02:43 -0800, Linus Torvalds wrote:
>
> On Wed, 27 Jan 2010, Peter Zijlstra wrote:
> >
> > Right, so you're going to love uprobes, which does exactly that. The
> > current proposal is overwriting the target instruction with an INT3 and
> > injecting an extra
On Wed, Jan 27, 2010 at 12:08:31PM +0100, Peter Zijlstra wrote:
> On Wed, 2010-01-27 at 16:35 +0530, Ananth N Mavinakayanahalli wrote:
> > Probing RIP-relative instructions work just fine; there are fixups that
> > take care of it.
>
> Ah my bad then, it was my understanding you simply bailed on
On Wed, 2010-01-27 at 16:35 +0530, Ananth N Mavinakayanahalli wrote:
> Probing RIP-relative instructions work just fine; there are fixups that
> take care of it.
Ah my bad then, it was my understanding you simply bailed on those.
Just for my information, how large are the replacement sequences?
* Linus Torvalds [2010-01-27 02:43:39]:
>
>
> On Wed, 27 Jan 2010, Peter Zijlstra wrote:
> >
> > Right, so you're going to love uprobes, which does exactly that. The
> > current proposal is overwriting the target instruction with an INT3 and
> > injecting an extra vma into the target process's
On Wed, 27 Jan 2010, Peter Zijlstra wrote:
>
> Right, so there's two aspects:
>
> 1) concurrency when inserting the probe
That's the one I worried about. Stopping all threads will fix it,
obviously at a disastrous performance cost, but what do I care? As noted,
there are ways to do it safel
On Wed, Jan 27, 2010 at 11:55:16AM +0100, Peter Zijlstra wrote:
> On Wed, 2010-01-27 at 02:43 -0800, Linus Torvalds wrote:
> >
> > On Wed, 27 Jan 2010, Peter Zijlstra wrote:
> > >
> > > Right, so you're going to love uprobes, which does exactly that. The
> > > current proposal is overwriting the
On Wed, 2010-01-27 at 11:55 +0100, Peter Zijlstra wrote:
> Right, so there's two aspects:
>
> 1) concurrency when inserting the probe
> 2) concurrency when hitting the probe
>
> 1) used to be dealt with by using utrace to stop all threads in the
> process and then writing the instruction. I sug
On Wed, 2010-01-27 at 02:43 -0800, Linus Torvalds wrote:
>
> On Wed, 27 Jan 2010, Peter Zijlstra wrote:
> >
> > Right, so you're going to love uprobes, which does exactly that. The
> > current proposal is overwriting the target instruction with an INT3 and
> > injecting an extra vma into the targ
On Wed, 27 Jan 2010, Peter Zijlstra wrote:
>
> Right, so you're going to love uprobes, which does exactly that. The
> current proposal is overwriting the target instruction with an INT3 and
> injecting an extra vma into the target process's address space
> containing the original instruction(s)
* Peter Zijlstra wrote:
> On Tue, 2010-01-26 at 15:37 -0800, Linus Torvalds wrote:
> >
> > On Tue, 26 Jan 2010, Tom Tromey wrote:
> > >
> > > In non-stop mode (where you can stop one thread but leave the others
> > > running), gdb wants to have the breakpoints always inserted. So,
> > > somet
On Tue, 2010-01-26 at 15:37 -0800, Linus Torvalds wrote:
>
> On Tue, 26 Jan 2010, Tom Tromey wrote:
> >
> > In non-stop mode (where you can stop one thread but leave the others
> > running), gdb wants to have the breakpoints always inserted. So,
> > something must emulate the displaced instructi
tromey wrote:
> [...]
> In non-stop mode (where you can stop one thread but leave the others
> running), gdb wants to have the breakpoints always inserted. So,
> something must emulate the displaced instruction.
This sounds like the sort of thing that kernel kprobes do, which the
uprobes patch
On Tue, 26 Jan 2010, Tom Tromey wrote:
>
> In non-stop mode (where you can stop one thread but leave the others
> running), gdb wants to have the breakpoints always inserted. So,
> something must emulate the displaced instruction.
I'm almost totally uninterested in breakpoints that actually re
On 01/26, Andi Kleen wrote:
>
> > Simple example. Try to debug/strace strace ot gdb itself. Not trivial,
> > you can't attach to strace's tracees. Recently I spent 2 days trying to
> > understand why strace -f hangs. I was able to attach to strace, but
> > I wasn't able to see what its tracees do.
Tom> * Use an fd, not SIGCHLD+wait, to report inferior state changes to gdb.
Tom> Internally we're already using a self-pipe to integrate this into
Tom> gdb's main loop. Relatedly, don't mess with the inferior's parentage.
Andi> How would having a kernel based solution be better over your
Andi> u
> "Linus" == Linus Torvalds writes:
Tom> * Support "displaced stepping" in the kernel; I think this would improve
Tom> performance when debugging in non-stop mode.
Linus> Don't we already do that at least on x86?
I don't know. If it does, and gdb does not yet use that, then that
would be w
> Simple example. Try to debug/strace strace ot gdb itself. Not trivial,
> you can't attach to strace's tracees. Recently I spent 2 days trying to
> understand why strace -f hangs. I was able to attach to strace, but
> I wasn't able to see what its tracees do.
But what would the semantics be insid
On 01/26, Andi Kleen wrote:
>
> But when I did that i couldn't come up with a good scenario
> where multiple debuggers actually make sense. In a sense
> being a debugger is really a very "intimate" thing for process. Do you
> really want to have multiple of them messing with each other?
>
> If yes
On 01/26, Linus Torvalds wrote:
>
> The problem is that anything that is based on reparenting and signals is
> fundamentally a "one parent only" kind of interface. See?
Indeed. signals + do_wait() is the horrible model.
> So the reason I think using an fd is a good idea is _not_ because gdb
> alr
> The problem is that anything that is based on reparenting and signals is
> fundamentally a "one parent only" kind of interface. See?
I was actually thinking about that before I wrote the email.
But when I did that i couldn't come up with a good scenario
where multiple debuggers actually make s
On Tue, 26 Jan 2010, Andi Kleen wrote:
> Tom Tromey writes:
>
> > * Use an fd, not SIGCHLD+wait, to report inferior state changes to gdb.
> > Internally we're already using a self-pipe to integrate this into
> > gdb's main loop. Relatedly, don't mess with the inferior's parentage.
>
> Ho
Tom Tromey writes:
> * Use an fd, not SIGCHLD+wait, to report inferior state changes to gdb.
> Internally we're already using a self-pipe to integrate this into
> gdb's main loop. Relatedly, don't mess with the inferior's parentage.
How would having a kernel based solution be better over yo
On Tue, Jan 26, 2010 at 08:28:15AM -0800, Linus Torvalds wrote:
> I already said earlier that I'd be perfectly happy to merge utrace code,
> as long as it was clear that I'm not merging a platform for crazy work.
> IOW, the end result might be merging 99% of the code, but I want to set
> peoples
On Tue, 26 Jan 2010, Johannes Stezenbach wrote:
>
> 1. If you'd merge utrace + ptrace-on-utrace, but never anything else
>which uses the utrace API, wouldn't it still be an improvement?
I already said earlier that I'd be perfectly happy to merge utrace code,
as long as it was clear that I'
On Mon, Jan 25, 2010 at 04:07:21PM -0800, Linus Torvalds wrote:
> 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 s
Hi -
On Mon, Jan 25, 2010 at 02:05:54PM -0700, Tom Tromey wrote:
> [...]
> Nevertheless, if the Linux kernel were to present a new user-space API,
> and if it had an advantage over ptrace, then we would port GDB to use
> it. There are other platforms where, IIRC, we now use some /proc thing
> ins
On Mon, Jan 25, 2010 at 01:41:57PM -0800, Linus Torvalds wrote:
>
>
> On Mon, 25 Jan 2010, Tom Tromey wrote:
...
> > * Support "displaced stepping" in the kernel; I think this would improve
> > performance when debugging in non-stop mode.
>
> Don't we already do that at least on x86? Just do
On Fri 2010-01-22 08:43:18, valdis.kletni...@vt.edu wrote:
> On Fri, 22 Jan 2010 10:51:39 +0530, Ananth N Mavinakayanahalli said:
>
> > FWIW, Oleg's implementation of ptrace over utrace is 100% compatible
> > with legacy ptrace; gdb testsuite indicates that
> > (http://lkml.org/lkml/2009/12/21/98)
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 a
Let me add my two euro-cents to this discussion.
Mark Wielaard :
> 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
> jailing an
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-pip
> "Linus" == Linus Torvalds 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 user-space API,
and 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
* Thomas Gleixner 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 also
>
On Mon, 2010-01-25 at 09:36 -0800, Linus Torvalds wrote:
> Upon the information that people are talking about magic new kernel
> interfaces to do fancy things. And talking about doing things with it that
> are simply not relevant for ptrace/strace.
Unfortunately ptrace does all that magic alread
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 a
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:
>
> 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 s
> 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 s
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
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 w
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 talkin
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 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
On Mon, 2010-01-25 at 10:29 +0530, Ananth N Mavinakayanahalli wrote:
> - Extend perf; would perf then use utrace underneath? Or would one have
> to redo some of what utrace already does for thread level control?
No, perf is about monitoring/tracing not modifying. Its about minimal
interference,
On Sun, Jan 24, 2010 at 08:42:13PM -0500, Kyle Moffett wrote:
>
> Personally I don't give a flying about SystemTap; I'm interested
> in things like the ability to stack gdb with strace, the RFC gdb-stub
> posted a week ago, etc. None of those abilities would be out-of-tree
> modules at all,
On Sat, Jan 23, 2010 at 12:23:33PM +0100, Ingo Molnar wrote:
>
> * Kyle Moffett wrote:
>
> > On Fri, Jan 22, 2010 at 19:22, Linus Torvalds
> > wrote:
...
> In that sense it might be better to fix/enhance ptrace, if there's interest.
> I've written a handful of ptrace extensions in the past
On Sat, Jan 23, 2010 at 14:48, wrote:
> The fundamental issue which Ingo is trying to say (and which you
> apparently don't seem to be understanding) is that utrace doesn't
> export a syscall (which is an ABI that we are willing to promise will
> be stable), but rather a set of kernel API's (whic
On 01/24/10 13:01, Frank Ch. Eigler wrote:
... all add up to a mere nudge away from entirely "evil". If so, I
wonder if your sort of grossly bimodal view of ethical virtue is going
to foster the right sorts of change in the linux kernel community.
Nothing like a good religious debate to l
Hi -
tytso wrote:
> [...]
Let me see if I can paraphrase those of your concerns that were substantive:
1) That if utrace is merged, and systemtap keeps on using it, there may be
some sort of chilling effect on kernel developers that would impede
utrace's future development.
This might sou
On Sat, 23 Jan 2010, Frank Ch. Eigler wrote:
> On Sat, Jan 23, 2010 at 07:04:01AM +0100, Ingo Molnar wrote:
>
> > [...] Also, if any systemtap person is interested in helping us
> > create a more generic filter engine out of the current ftrace filter
> > engine (which is really a precursor of a s
Hi -
On Sun, Jan 24, 2010 at 05:25:13AM -0500, ty...@mit.edu wrote:
> [...]
> > > The killer app for this will be the ability to delete thousands of
> > > lines of code from GDB, strace, and all the various other tools that
> > > have to painfully work around the major interface gotchas of ptrace(
On Sat, Jan 23, 2010 at 09:04:56PM -0800, Linus Torvalds wrote:
> > The killer app for this will be the ability to delete thousands of
> > lines of code from GDB, strace, and all the various other tools that
> > have to painfully work around the major interface gotchas of ptrace(),
> > while at the
On Sat, 23 Jan 2010, Kyle Moffett wrote:
>
> Now how do we get from here to a moderately portable API for
> interrogating, controlling, and intercepting process state?
Umm? ptrace?
It's not _pretty_, but it's a hell of a lot more portable than utrace is
ever going to be. Yes, the details diff
On Sat, Jan 23, 2010 at 06:47:29AM -0500, Frank Ch. Eigler wrote:
> > What utrace does is that it provides an opaque set of APIs for
> > unspecified and out of tree _kernel_ modules (such as systemtap). It
> > doesnt support any 'application' per se. It basically removes the
> > kernel's freedom at
Em Sat, Jan 23, 2010 at 11:01:21AM +, Alan Cox escreveu:
> Years ago (and it really must be years ago because this was about the
> time I started hacking on Linux stuff !) there was a proposal to extract
> and sanitize the arch specific stuff in binutils and in gdb etc into
> sensible libraries
Hi -
On Sat, Jan 23, 2010 at 07:04:01AM +0100, Ingo Molnar wrote:
> [...] Also, if any systemtap person is interested in helping us
> create a more generic filter engine out of the current ftrace filter
> engine (which is really a precursor of a safe, sandboxed in-kernel
> script engine), that w
Hi -
On Sat, Jan 23, 2010 at 11:01:21AM +, Alan Cox wrote:
> [...]
> What I don't understand is why [libgdb?] doesn't solve 99% of your problem.
> ptrace is not perfect but most of the real ptrace limitations actually
> come about because either the CPU can't do something or because the
> supp
Hi -
mingo wrote:
> [...]
> > Now how do we get from here to a moderately portable API for interrogating,
> > controlling, and intercepting process state? Essentially it would need to
> > support all of the things that a powerful debugger would want to do,
> > including modifying registers and
* Kyle Moffett wrote:
> On Fri, Jan 22, 2010 at 19:22, Linus Torvalds
> wrote:
> > There are cases where we really _want_ to have common code. We want to
> > have a common VFS interface because we want to show _one_ interface to
> > user space across a gazillion different filesystems. We want t
> The killer app for this will be the ability to delete thousands of
> lines of code from GDB, strace, and all the various other tools that
> have to painfully work around the major interface gotchas of ptrace(),
> while at the same time making their handling of complex processes much
> more robust
On Sat, Jan 23, 2010 at 2:22 AM, Linus Torvalds
wrote:
> This is why when somebody brought up "you could do a seccomp-like thing on
> top of utrace" that my reaction was and is just totally negative. It shows
> all the wrong kinds of tying things together.
seccomp-via-utrace should be just remove
On Fri, Jan 22, 2010 at 19:22, Linus Torvalds
wrote:
> There are cases where we really _want_ to have common code. We want to
> have a common VFS interface because we want to show _one_ interface to
> user space across a gazillion different filesystems. We want to have a
> common driver layer (as
* Linus Torvalds wrote:
> On Thu, 21 Jan 2010, Frank Ch. Eigler wrote:
>
> > Less passionate analysis would identify a long history of contribution by
> > the the greater affiliated team, including via merged code and by and
> > passing on requirements and experiences.
>
> The reason I'm so
On Fri, 22 Jan 2010, Linus Torvalds wrote:
>
> No. It's not about naming. It's about the downside of having amorphous
> interfaces that apparently don't even have rules, and are then used to
> implement random crap.
>
> Yes, the SNL skit about "It's a dessert topping _and_ a floor wax" was
>
On Fri, 22 Jan 2010, Frank Ch. Eigler wrote:
>
> The point is that the intermediate api will allow (and, as the part
> you clipped out about utrace-gdbstub said, *already has allowed*)
> alternative plausible interfaces that coexist just fine.
And my point is that multiple interfaces are BAD.
Hi -
On Fri, Jan 22, 2010 at 01:59:11PM -0800, Linus Torvalds wrote:
> [...]
> > Finally, I don't know how to address the logic of "if a feature
> > requires utrace, that's a bad argument for utrace" and at the same
> > time "you need to show a killer app for utrace". What could possibly
> > sati
On Fri, 22 Jan 2010, Frank Ch. Eigler wrote:
>
> Finally, I don't know how to address the logic of "if a feature
> requires utrace, that's a bad argument for utrace" and at the same
> time "you need to show a killer app for utrace". What could possibly
> satisfy both of those constraints? Plea
Hi -
On Fri, Jan 22, 2010 at 09:16:16PM +0100, Peter Zijlstra wrote:
> [...]
> > So then there's uprobes, which is another potential utrace "killer
> > app"
> That's bollocks, uprobes is an utter and total mis-match for utrace.
> Probing userspace is primarily about DSOs which is files and vma's,
On 01/21, Linus Torvalds wrote:
>
> I realize that my argument is very anti-thetical to the normal CS teaching
> of "general-purpose is good". I often feel that very specific code with
> very clearly defined (and limited) applicability is a good thing - I'd
> rather have just a very specific ptrace
On Fri, 2010-01-22 at 15:01 -0500, Frank Ch. Eigler wrote:
> So then there's uprobes, which is another potential utrace "killer
> app"
That's bollocks, uprobes is an utter and total mis-match for utrace.
Probing userspace is primarily about DSOs which is files and vma's, not
tasks.
You might mayb
Hi -
oleg wrote:
> [...]
>> I'm personally very dubious that there are any merits to utrace that
>> outweigh the very clear disadvantages: just another layer that adds a new
>> level of abstraction to the only interface that people actually _use_,
>> namely ptrace.
>
> Of course they can't use ot
On 01/22, valdis.kletni...@vt.edu wrote:
>
> No, that only proves it's compatible enough for gdb to not care. The problem
> is all those *other* packages that abuse ptrace in totally crackhead ways.
>
> (No, I can't name them - but ptrace is the sort of interface that almost
> encourages its use fo
On 01/21, Linus Torvalds wrote:
>
> On Thu, 21 Jan 2010, Andrew Morton wrote:
> >
> > ptrace is a nasty, complex part of the kernel which has a long history
> > of problems, but it's all been pretty quiet in there for the the past few
> > years.
>
> More importantly, we're not ever going to get rid
1 - 100 of 128 matches
Mail list logo
