[ltt-dev] [RFC UST] Processes model

[Michel Dagenais]

> >     Consumer creation - spawns ust-consumerd.
> 
> No ? Isn't ust-consumerd spawned separately, and then connects to ustd

In which case it could be a consumer, not a daemon. In a sense strace is similar as it receives the tracing information from the kernel through ptrace and writes it to disk; yet even if it can be backgrounded, it is not called a daemon.

> I don't think it is needed. ustd runs as root, and if we have a bug in
> the tracer, well, we have a bug in the tracer, that's it.
> 
> The in-kernel LTTng does not save state to disk. If the tracer crashes
> in the kernel, we try not to kill the whole box, but the user cannot expect
> to be able to trace until the box reboots.

Yes, I would avoid that complexity initially, and bring back the idea if there is a compelling reason.

> lttngtrace is a bit verbose. Maybe "ostrace" (as in OS Trace) ? Other
> suggestions ?

Should the same command be used kernel and ust:

trace -p process_1    -> ust tracing of process 1
trace -k -p process_1 -> ust + kernel tracing of process 1
trace -k              -> whole system tracing

Possible names? Quite a few are taken!
 Command 'btrace' from package 'blktrace' (universe)
 Command 'itrace' from package 'irpas' (multiverse)
 Command 'ltrace' from package 'ltrace' (main)
 Command 'etrace' from package 'etrace' (universe)
 Command 'mtrace' from package 'libc-dev-bin' (main)
 Command 'tracer' from package 'pvm-dev' (universe)
 Command 'grace' from package 'grace' (universe)
 Command 'xtrace' from package 'xtrace' (universe)
 Command 'tracd' from package 'trac' (universe)
 Command 'strace' from package 'strace' (main)
 Command 'dtrace' from package 'systemtap-sdt-dev' (universe)
 Command 'rtrace' from package 'radiance-sse3' (universe)
 Command 'rtrace' from package 'radiance' (universe)
 trace: command not found

Is trace actually available?!


> Why should ustd fork the ust-consumerd ?
> 
> Also, we will need to represent the pipe communication between
> ust-consumerd and
> ustd. It is needed to control the buffer access (get/put subbuffer
> operations).
> If we use a named pipe for this, the access rights will probably need
> to be
> u+rw and g+rw (write access for group tracing too, to send commands).

More details are required to understand what happens before/after setuid, when subsequent modifications are required to the tracing session (tracepoint activation).