>> We've spent quite a lot of effort explaining the problems with the
>> utrace/uprobes dependency
> Can you provide some links to discussion about these specifics: ?
Um, just use a search ... if you search lkml for utrace you get the less polite version .. if you search the systemtap lists on the same thing, you get the more polite one.
>> (especially the issues of having to pull the
>> process symbol table into the kernel
> User-space symbol tables are made available to the systemtap module
> only if it is required by the script - if it performs symbolic
> address or backtrace type lookups.
Only if you buy the premise that the kernel has to be intimately involved in the trace instead of being a simple conduit for mediating it.
>> and of having the kernel actually
>> execute the compiled code to do the traps
> Like in dtrace, instrumentation is run within the kernel because
> having user-space processes instrument each other is too disruptive.
> We're looking for microsecond-level probe effect, not something
> involving multiple context switches, indirect address space accesses,
> and so on.
Well, this would be the classic illustration of the problems systemtap faces. Nothing on the above laundry list is impossible even if the kernel merely controls the traced process and lets userspace poke at it ... that, after all, is how gdb works. The brick wall is that kernel developers don't think this is at all a compelling argument and apparently systemtap people think it is.