linux-kernel - Re: Re: [RFC PATCH 08/11] trace-cmd: Apply the trace-msg protocol for communication between a server and clients

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <521AB469.40201@hitachi.com>
Date:	Mon, 26 Aug 2013 10:50:33 +0900
From:	Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@...achi.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Hidehiro Kawai <hidehiro.kawai.ez@...achi.com>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	linux-kernel@...r.kernel.org, yrl.pp-manager.tt@...achi.com
Subject: Re: Re: [RFC PATCH 08/11] trace-cmd: Apply the trace-msg protocol
 for communication between a server and clients

(2013/08/21 2:56), Steven Rostedt wrote:
> On Mon, 19 Aug 2013 18:46:39 +0900
> Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@...achi.com> wrote:
>
>
>> This message protocol is incompatible with the previous unstructured message
>> protocol. So, if an old(new)-version client tries to connect to an
>> new(old)-version server, the operation should be stopped.
>>
>
> I'm a stickler for backward compatibility. I'm all for extensions.

No problem:)
I also worried about backward compatibility.

> I know this will just complicate things, but I don't mind that. What
> should happen is, it should try to connect with the new protocol, if it
> fails due to an older server, then it needs to fall back to the older
> method, without the added features. We can freeze the older method if
> need be. But I will not let a newer trace-cmd become incompatible with
> an older version. I worked hard to keep it that way. There's only a few
> exceptions to that.
>
> Note, an older client needs to also work as is with a newer server.
>
> Anyway, the old way only needs to stay the same, it does not need added
> features. For that, a switch to the new way is needed.

OK, I'll add the code switching to the new way in order to keep backward
compatibility. Would you give me your comments about following things?

<Network>
0. old server and old client
Old servers send "tracecmd" as the first message.
Old clients compare the first 8byte of the first message with "tracecmd".

1. new server
- Send "tracecmd-v2" as the first message.
- Check the reply message whether the message is "tracecmd-v2" or cpus
   value.
   If "tracecmd-v2", the server uses new protocol and wait for the
   message MSG_TINIT.
   If cpus value, the server uses old protocol.

2. new client
- Receive the first message.
- Check the message whether the message is "tracecmd-v2" or not.
   If "tracecmd-v2", the client sends "tracecmd-v2" to the server. Then,
   the client sends the message MSG_TINIT.
   If "tracecmd", the client sends cpus value as the old protocol.

<Virtio-serial>
This is new feature, so trace-cmd does not need to keep backward
compatibility.

> If you need help in accomplishing this, I'll work with you on that.

Thank you for your kindness!

Yoshihiro YUNOMAE

-- 
Yoshihiro YUNOMAE
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: yoshihiro.yunomae.ez@...achi.com


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/