On Mon, Nov 26, 2018 at 8:06 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > On Wed, 14 Nov 2018 17:43:28 +0200 > kaslevs@xxxxxxxxxx wrote: > > > From: Slavomir Kaslev <kaslevs@xxxxxxxxxx> > > > > 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@xxxxxxxxxx> > > --- > > > > 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
|