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 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
