[ltt-dev] UST socket protocol

[Pierre-Marc Fournier]

On 09/09/2010 11:45 AM, Nils Carlson wrote:
>
>
> 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.
>

Sorry I'm quite late in my emails. The reason for this design choice is 
the following. Readable text is the traditional unix way of doing things 
and is arguably one of the key reasons of its success. It's much easier 
to debug because it's human readable. You can see the protocol in strace 
output for example. Usually, binary protocols are reserved for cases 
where getting the best performance possible is critical. It is not the 
case here. It might still be possible to argue a binary protocol would 
be a better choice but that is not obvious to me at this point.

pmf