[RFC] gradually moving strace from ptrace to perf

[Denys Vlasenko]

On 09/24/2013 03:11 PM, Jan Kratochvil wrote:
> On Tue, 24 Sep 2013 14:51:41 +0200, Denys Vlasenko wrote:
>> What happens here is that traced process exited by the time
>> strace saw open() syscall data. Fetching of filename didn't
>> succeed, strace got ESCRH trying to do that:
> 
> I had some alternative attempt using systemtap instead:
> 	http://post-office.corp.redhat.com/archives/perftools-list/2011-February/msg00008.html
> That download URL is invalid there now:
> 	git clone git://git.jankratochvil.net/staptrace 
> 	http://git.jankratochvil.net/?p=staptrace.git;a=blob;f=src/staptrace.stp
> 
> The whole output trace line is created in kernel so it has access to all the
> needed parameters content.

I'm not too familiar with systemtap, please correct me if
I'm wrong anywhere in my musings below:

IIUC, this approach, if implemented fully, would move
most of strace's syscall decoding machinery to kernel,
what would be passed back to userspace are the strings
of generated output.

I don't see this as a bad design outright:
in many difficult debug situations, will people trade
such an intrusion in the kernel space for the large
performance enhancement? Yes, in a heartbeat.

If code size is a concern, it can be a compiled as a module
and insmod'ed only when needed.

To do something like this, I would want to reuse strace's
C code of syscall decoders with as small modifications
as possible (i.e. want to avoid a complete rewrite,
especially to a different language).
Is this achievable with systemtap?

Will it be possible to use systemtap-based
strace by non-root users?

-- 
vda