Hello everyone, While writing a manual for lttng-agent, I noticed that a lot functionality is missing when controlling ust traces. The following is a list of known issues and hints on how to address them, for anyone interested. I will also put this info in the lttng-agent git repo, in the TODO file.
As it is, lttng-agent can create, configure, start, stop and destroy kernel traces and can stream the data across the network. It can also do most of these things with ust traces, including streaming. There are however a lot of commands that are not supported by the ust provider. The following commands are accepted by the kernel provider but not the ust provider: allocTrace getActiveTraceInfo getActiveTraces getTraces setChannelEnable setChannelOverwrite setChannelSubbufNum setChannelSubbufSize setMarkerEnable setTraceTransport stopWriteTraceLocal The following commands are accepted but do not work exactly in the same way: setChannelTimer setupTrace writeTraceLocal writeTraceNetwork One of the main cause of these problems is missing functions in the ustcmd library used to communicate with the traced process. In particular, it lacks a simple setup function. It only supplies a setup_and_start function, which is essentially an aggregate of setup, alloc and start. This causes two problems. First, we can't create the trace, change subbuffer count/size and then allocate the trace, as it is done in a single operation. Second, as the trace is started right away, it needs to connect to a daemon to request collection. If we want to stream the data, we have to tell ust to connect to the agent before we create the trace, or it will default to the local global ustd daemon. This causes a weird requirement to call writeTraceNetwork, specifying a trace which does not exist yet, and then create the trace with setupTrace. In addition to being a counterintuitive way to do things, this is not the way it works for the kernel provider. This could cause problems for higher-level tools like the eclipse control plugin, which, I believe, makes no distinction between a ust trace and a kernel trace. There are already ustcmd functions to alloc and start the trace. Adding one to only do the setup would help fix the problems with allocTrace, setChannelSubbufNum, setChannelSubbufSize, setupTrace and writeTraceNetwork. I believe libust is already setup to do this, it just needs to be exposed throught ustcmd. getActiveTraceInfo, getActiveTraces, setChannelEnable, setChannelOverwrite and getTraces would also need added functionality in ustcmd. I'm not sure about the implications of implementing stopWriteTraceLocal, as the local tracing is currently done in another process (ustd). setChannelTimer does not set a per-channel timer, but instead uses a single timer for all channels and for all traces the agent monitors. This was done as a first step and will probably need to be elaborated a bit. As for the remaining commands, setTraceTransport is not needed, and I see no obstacle to the implemention of setMarkerEnable. Hopefully these issues can be addressed in the near future, but in the meantime they are documented in the manual. Alexis _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
