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