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
On Mon, 8 Feb 2010 07:54:25 +0100
Pavel Machek pa...@ucw.cz 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
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
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 the
old code
On Fri, 2010-01-29 at 08:42 +0100, Ingo Molnar wrote:
* Ananth N Mavinakayanahalli ana...@in.ibm.com 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
* Ananth N Mavinakayanahalli ana...@in.ibm.com 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
On Fri, Jan 29, 2010 at 10:11:16AM +0100, Ingo Molnar wrote:
* Ananth N Mavinakayanahalli ana...@in.ibm.com 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
* Ananth N Mavinakayanahalli ana...@in.ibm.com wrote:
On Fri, Jan 29, 2010 at 10:11:16AM +0100, Ingo Molnar wrote:
* Ananth N Mavinakayanahalli ana...@in.ibm.com wrote:
On Fri, Jan 29, 2010 at 08:39:07AM +0100, Ingo Molnar wrote:
...
When we merged kprobes ~10 years
Ingo Molnar mi...@elte.hu 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
* Jim Keniston jkeni...@us.ibm.com 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
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 for
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 the
On Thu, 2010-01-28 at 09:55 +0100, Ingo Molnar wrote:
* Jim Keniston jkeni...@us.ibm.com 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
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 |
* Peter Zijlstra pet...@infradead.org 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,
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) and
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 target
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 suggested
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 target
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 safely
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?
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 those.
[ 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 vma into
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 address
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
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 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 doing a
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
instead
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 simply
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'm
Tom Tromey tro...@redhat.com 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
On Tue, 26 Jan 2010, Andi Kleen wrote:
Tom Tromey tro...@redhat.com 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
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
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
already
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 how
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 inside
Linus == Linus Torvalds torva...@linux-foundation.org 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,
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 user
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.
But
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
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 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
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 same
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, 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 safe,
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
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
On Sat, Jan 23, 2010 at 14:48, ty...@mit.edu 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
On Sat, Jan 23, 2010 at 12:23:33PM +0100, Ingo Molnar wrote:
* Kyle Moffett k...@moffetthome.net wrote:
On Fri, Jan 22, 2010 at 19:22, Linus Torvalds
torva...@linux-foundation.org wrote:
...
In that sense it might be better to fix/enhance ptrace, if there's interest.
I've written a
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, and
On Sat, Jan 23, 2010 at 2:22 AM, Linus Torvalds
torva...@linux-foundation.org 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.
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.
* Kyle Moffett k...@moffetthome.net wrote:
On Fri, Jan 22, 2010 at 19:22, Linus Torvalds
torva...@linux-foundation.org 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
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 memory,
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
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
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
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 differ
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 of it.
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 other
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 maybe
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 layer
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,
not
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
satisfy both of
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.
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
funny,
On Fri, Jan 22, 2010 at 19:22, Linus Torvalds
torva...@linux-foundation.org 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
Hi -
On Thu, Jan 21, 2010 at 04:31:45PM -0800, Andrew Morton wrote:
[...]
Someone please sell this to us.
Here's what Oleg said last time I asked this: [...]
I wonder if Roland/Oleg are being too modest in their current role as
ptrace maintainers. Considering that *they* think of utrace as
Hi -
On Thu, Jan 21, 2010 at 05:05:41PM -0800, 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. This leads one to expect that a
rip-out-n-rewrite is a high-risk
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 of it.
Quite frankly, judging my all past
On Thu, 21 Jan 2010, Frank Ch. Eigler wrote:
To the extent the discussion is colored by the new features enabled
from this refactoring, well, there is Oleg's list which may or may not
have mentioned enabling systemtap's user-space probing.
Let's face it, system tap isn't going to be
Hi -
On Thu, Jan 21, 2010 at 05:32:47PM -0800, Linus Torvalds wrote:
[...]
To the extent the discussion is colored by the new features enabled
from this refactoring, well, there is Oleg's list which may or may not
have mentioned enabling systemtap's user-space probing.
Let's face it,
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 passionate is that I dislike the turn the
On Thu, Jan 21, 2010 at 05:28:42PM -0800, 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
Hi Roland, Oleg,
Would it be a good idea to probably start looking at user space api for
utrace? By doing that we would get usecases that maintainers in LKML are
looking for and start looking at its usefulness.
Currently its probably a egg and chicken case where they look at what
end customers
On Wed, Jan 20, 2010 at 12:10:26PM +0530, Ananth N Mavinakayanahalli wrote:
It will cause conflicts with various other trees and increases the overhead
all around. It also causes us to trust linux-next bugreports less - as it's
not the 'next Linux' anymore. Also, there's virtually no
Hi -
On Wed, Jan 20, 2010 at 05:59:59PM +1100, Stephen Rothwell wrote:
[...]
Including experimental code that is RFC and which is not certain to go
upstream is certainly not the purpose of linux-next though.
Ingo is correct in what he says here. See the boilerplate:
[...]
Basically,
Frank, please be clear as to which branch you want included (master or
utrace-ptrace). Also note that neither of those branches matches what
was posted in the sense that they both have lots of history and merges
not represented in the patches. (I assume that they do produce the same
final
Hi Frank,
On Tue, 19 Jan 2010 16:16:46 -0500 Frank Ch. Eigler f...@redhat.com wrote:
Having been reviewed a couple of times, and we hope being a good
candidate for merging next time, please start pulling
git://git.kernel.org/pub/scm/linux/kernel/git/frob/linux-2.6-utrace.git
branch master
On Wed, Jan 20, 2010 at 06:49:50AM +0100, Ingo Molnar wrote:
Ingo,
Note, i'm not yet convinced that this (and the rest: uprobes and systemtap,
etc.) can go uptream in its present form.
Agreed, uprobes is still not upstream ready -- it was an RFC. We are
working through the comments there to
Hi Frank,
On Wed, 20 Jan 2010 07:28:34 +0100 Ingo Molnar mi...@elte.hu wrote:
Including experimental code that is RFC and which is not certain to go
upstream is certainly not the purpose of linux-next though.
Ingo is correct in what he says here. See the boilerplate:
* destined for
* Ingo Molnar mi...@elte.hu wrote:
* Ananth N Mavinakayanahalli ana...@in.ibm.com wrote:
On Wed, Jan 20, 2010 at 06:49:50AM +0100, Ingo Molnar wrote:
Ingo,
Note, i'm not yet convinced that this (and the rest: uprobes and
systemtap,
etc.) can go uptream in its present
96 matches
Mail list logo
