[lkml]   [2010]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: linux-next: add utrace tree
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, substituting syscall return
> > values, etc. I believe that "utrace" is the kernel side of that API.
> The problem is, utrace does not do that really.

In fact, it is exactly designed for that.

> 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 shaping its own interaction with debug
> application.

This claim is hard to take any more seriously than emoting that the
blockio layer is "opaque" because device drivers "remove freedom" for
the kernel to "shape its interaction" with hardware. If you have any
*real evidence* about how any present user of utrace misuses that
capability, or interferes with the "kernel's freedom", show us please.

- FChE

 \ /
  Last update: 2010-01-23 12:51    [W:0.218 / U:59.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site