On 2010-08-20 13:41, Alexandre Montplaisir wrote:
Hello everyone,
[...]
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.
Afaik, the UI in Eclipse-control shows both "kernel" and "user traces"
providers, and they go through different code paths, so the API
doesn't necessarily need to be identical for both. Still, as you say,
it would make it clear to have them at least similar.
In fact, the Eclipse UI shows both providers, but trust me, there are no
different code paths in eclipse to control the two different providers.
It just enumerates the different providers and tries to get information
about both.
Michael
Good stuff!
Alexandre
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
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
_______________________________________________
ltt-dev mailing list
[email protected]
http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
