[ltt-dev] lttng-agent and ust issues

* [ltt-dev] lttng-agent and ust issues
@ 2010-08-20 15:56 Alexis Hallé
  2010-08-20 17:41 ` Alexandre Montplaisir
  2010-08-24  3:45 ` Pierre-Marc Fournier
  0 siblings, 2 replies; 4+ messages in thread
From: Alexis Hallé @ 2010-08-20 15:56 UTC (permalink / raw)

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

^ permalink raw reply	[flat|nested] 4+ messages in thread