Re: [PATCH] trace-cmd: Fix record --date flag when sending tracing data to a listener

[Slavomir Kaslev <kaslevs@vmware.com>]

On Mon, Nov 26, 2018 at 8:06 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Wed, 14 Nov 2018 17:43:28 +0200
> kaslevs@vmware.com wrote:
>
> > From: Slavomir Kaslev <kaslevs@vmware.com>
> >
> > Currently the `trace-cmd record` --date is not taken into account when tracing
> > data is sent to a remote host with the -N flag.
> >
> > This patch fixes this by the writing output buffer options from the recording
> > side instead of on the listener side.
> >
> > Signed-off-by: Slavomir Kaslev <kaslevs@vmware.com>
> > ---
> >
>
> I don't see anything too wrong with it, accept the following test broke:
>
>  $ git checkout trace-cmd-v2.6
>  $ make
>  $ sudo cp trace-cmd /usr/local/bin/trace-cmd-v2.6
>  $ git checkout origin/master
>  $ patch -p1 < this.patch
>  $ make
>  $ trace-cmd-v2.6 listen -p 12345
>
> In another terminal:
>
>  $ sudo trace-cmd record -N 127.0.0.1:12345 -e sched sleep 1
> trace-cmd: No such file or directory
>   Cannot handle the protocol
>
>
> Remember, we need to remain backward compatible. We also need to test
> this code running as a listener, and the trace-cmd-v2.6 (and earlier)
> as the recorder.

This is a design bug (the best kind), metadata should really be written from the
recording side and not from the listener. A backward compatible fix should have
the newer recorder and listener detect they're talking to an older version and
fallback to broken behavior. This implies a new protocol version or extending
MSG_TINIT/MSG_RINIT so that we can infer the behavior on the other side and
fallback to being broken when necessary.

What would you suggest?

--
Slavi