> >     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).


_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev

Reply via email to