[ltt-dev] UST socket protocol

[ltt-dev] UST socket protocol

[Nils Carlson]

I've been looking through the socket protocol for UST and am a bit curious 
about the construction of it. Is there a reason we haven't just defined a 
ustctl package type with a command field, a result field and a data field?

This would reduce the amount of scanning required by quite a bit.

/Nils

[ltt-dev] UST socket protocol

[Michel Dagenais]

> I've been looking through the socket protocol for UST and am a bit
> curious about the construction of it. Is there a reason we haven't just
> defined a ustctl package type with a command field, a result field and a
> data field?
>
> This would reduce the amount of scanning required by quite a bit.

I have not looked closely at the protocol. Reusing an existing protocol 
would make sense. For instance, reusing the GDB protocol could be 
interesting since GDB is already capable of listing and activating UST 
tracepoints. Moreover, the GDB protocol is also used by kgdb to enable 
kernel dynamic tracepoints with kprobes with a recent patch. I doubt 
that the GDB protocol would be optimized for fast transfers of tracing 
data, but that may be transmitted through a separate channel.

The TCF protocol could be another candidate.

[ltt-dev] UST socket protocol

[Pierre-Marc Fournier]

On 09/07/2010 02:30 AM, Nils Carlson wrote:
> I've been looking through the socket protocol for UST and am a bit
> curious about the construction of it. Is there a reason we haven't just
> defined a ustctl package type with a command field, a result field and a
> data field?
>

Not sure I understand.

There is the socket protocol and there is the ustcmd API. The ustcmd API 
is there to make it easy to control tracing in a system from within a C 
program like TCF or ustctl. It in turn converts the commands it receives 
to the text-based ust socket protocol which libust (inside the traced 
app) is able to parse.

If I understand your question, you are asking why ustctl is not talking 
directly the socket protocol. The answer to that is that it used to do 
this. But the ustcmd api had to be introduced in order to allow other 
programs like TCF to control the tracing. The lttng TCF agent currently 
does this and depends on libustcmd.

pmf

[ltt-dev] UST socket protocol

[Nils Carlson]

On Thu, 9 Sep 2010, Pierre-Marc Fournier wrote:

> On 09/07/2010 02:30 AM, Nils Carlson wrote:
>> I've been looking through the socket protocol for UST and am a bit
>> curious about the construction of it. Is there a reason we haven't just
>> defined a ustctl package type with a command field, a result field and a
>> data field?
>>
>
> Not sure I understand.
>
> There is the socket protocol and there is the ustcmd API. The ustcmd API
> is there to make it easy to control tracing in a system from within a C
> program like TCF or ustctl. It in turn converts the commands it receives
> to the text-based ust socket protocol which libust (inside the traced
> app) is able to parse.

That's the one I'm reffering to. And what I'm asking is why it's using 
plain text to do option parsing and not some much simpler binary commands? 
As all the parts are part of libust and no traffic is going over a network 
you could more or less send whole structs and use enums for commands, this 
would reduce the amount of parsing code substantially.

/Nils