* Kyle Moffett <kyle@xxxxxxxxxxxxxxx> wrote: > On Fri, Jan 22, 2010 at 19:22, Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> 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 far as possible) because - again - we expose a > > metric shitload of drivers, and we want to have one unified interface to > > them. > > So... Everybody agrees that ptrace() is horrible and a royal pain to use, > let alone use correctly and without bugs. Everybody also agrees that > ptrace() needs to stay around for a long time to avoid breaking all the > existing users. > > 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. 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. If utrace was a 'better ptrace' syscall, where the syscall itself is the goal of the hookery, it would all be rather different. People could argue about _that_ interface (and the hooks would be a pure kernel internal implementational detail - not an interface specification), and once people agree about that ABI and there's enough application momentum behind it, the hooks are really not that opaque anymore - they are for that ABI and not more. Note that it's still a _big_ hurdle: it's hard to agree on a new syscall and it's hard to get 'application momentum' behind it. Special Linux system calls have a checkered past, they tend to not be used by much anything, and thus they tend to be a breeding ground of both bugs, maintenance complexity and security problems. Lack of attention is never good. 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 (none of them went upstream tho), it can be done in a useful manner and the code is pretty hackable. There are basic problems left to be solved: for example why is there still no 'memory block copy' call, why are we _still_ limited to one word per system call PTRACE_PEEK* memory copies? It's ridiculous. SparcLinux has PTRACE_WRITE*/READ* support that implements this, but none of the other architectures have it so it's essentially unused. Or another possible direction would be to extend the perf events syscall with interception capabilities. It's far more performant at extracting application state without scheduling than any ptrace method - and interception/injection would be a natural next step - if there's interest. Thanks, Ingo -- 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
