On Mon, Jan 18, 2010 at 02:15:51PM +0100, Peter Zijlstra wrote:
On Mon, 2010-01-18 at 14:37 +0200, Avi Kivity wrote:
On 01/18/2010 02:14 PM, Peter Zijlstra wrote:
Well, the alternatives are very unappealing. Emulation and
single-stepping are going to be very slow compared to a couple
On Fri, 2010-01-22 at 12:54 +0530, Ananth N Mavinakayanahalli wrote:
On Fri, Jan 22, 2010 at 12:32:32PM +0530, Srikar Dronamraju wrote:
Here is a summary of the Comments and actions that need to be taken for
the current uprobes patchset. Please let me know if I missed or
misunderstood any
Roland McGrath yazmış:
We don't have any particular plans to extend the ptrace interface.
I strongly doubt we would even try to do anything like that until the
utrace-based ptrace interface is merged into Linux and the old ptrace
implementation gone.
In general, we are not looking for
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.
Peter Zijlstra wrote:
On Fri, 2010-01-22 at 12:32 +0530, Srikar Dronamraju wrote:
2. XOL vma vs Emulation vs Single Stepping Inline vs using Protection
Rings.
XOL VMA is an additional process address vma. This is
opposition to add an additional vma without user actually
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, 2010-01-22 at 19:06 +0100, Peter Zijlstra wrote:
On Fri, 2010-01-22 at 12:32 +0530, Srikar Dronamraju wrote:
2. XOL vma vs Emulation vs Single Stepping Inline vs using Protection
Rings.
XOL VMA is an additional process address vma. This is
opposition to add an
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
14 matches
Mail list logo
