Re: Re: [RFC PATCH 08/11] trace-cmd: Apply the trace-msg protocol for communication between a server and clients
(2013/08/28 23:42), Steven Rostedt wrote: On Wed, 28 Aug 2013 20:30:17 +0900 Yoshihiro YUNOMAE wrote: (2013/08/27 22:05), Steven Rostedt wrote: On Tue, 27 Aug 2013 19:23:24 +0900 Yoshihiro YUNOMAE wrote: OK, let me check that. Even if the old server will receive "V2", the server will send port numbers instead of "V2" due to the old protocol. In that time, the new client will disconnect from the old server and the restarts with the old protocol. Is it OK? Yep, that's exactly what I meant ;-) I tried to implement the feature, but I found that sending just "V2" from the new client is inappropriate. This is because the old server doesn't respond to the client before receiving cpu numbers, page size, and options. So, when the new client sends the first message, it should send "V2\0\00\0", I think. If so, the old server will understand the message as cpus=0, pagesize=, options=0, and then it will send port numbers(actually \0). Note if is zero, the old server will die. Can I implement the first message of the new client as "V2\0\00\0"? If it works for both old and new server with old and new client (and all combinations) I'm fine with it. OK, I'll submit trace-cmd patches as V2 in a few days. Thanks, Yoshihiro YUNOMAE -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 08/11] trace-cmd: Apply the trace-msg protocol for communication between a server and clients
On Wed, 28 Aug 2013 20:30:17 +0900 Yoshihiro YUNOMAE wrote: > (2013/08/27 22:05), Steven Rostedt wrote: > > On Tue, 27 Aug 2013 19:23:24 +0900 > > Yoshihiro YUNOMAE wrote: > > > >> OK, let me check that. Even if the old server will receive "V2", the > >> server will send port numbers instead of "V2" due to the old protocol. > >> In that time, the new client will disconnect from the old server and > >> the restarts with the old protocol. Is it OK? > > > > Yep, that's exactly what I meant ;-) > > I tried to implement the feature, but I found that sending just "V2" > from the new client is inappropriate. This is because the old server > doesn't respond to the client before receiving cpu numbers, page size, > and options. So, when the new client sends the first message, it should > send "V2\0\00\0", I think. If so, the old server will > understand the message as cpus=0, pagesize=, options=0, > and then it will send port numbers(actually \0). Note if > is zero, the old server will die. > > Can I implement the first message of the new client as > "V2\0\00\0"? > If it works for both old and new server with old and new client (and all combinations) I'm fine with it. Thanks, -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFC PATCH 08/11] trace-cmd: Apply the trace-msg protocol for communication between a server and clients
(2013/08/27 22:05), Steven Rostedt wrote: On Tue, 27 Aug 2013 19:23:24 +0900 Yoshihiro YUNOMAE wrote: OK, let me check that. Even if the old server will receive "V2", the server will send port numbers instead of "V2" due to the old protocol. In that time, the new client will disconnect from the old server and the restarts with the old protocol. Is it OK? Yep, that's exactly what I meant ;-) I tried to implement the feature, but I found that sending just "V2" from the new client is inappropriate. This is because the old server doesn't respond to the client before receiving cpu numbers, page size, and options. So, when the new client sends the first message, it should send "V2\0\00\0", I think. If so, the old server will understand the message as cpus=0, pagesize=, options=0, and then it will send port numbers(actually \0). Note if is zero, the old server will die. Can I implement the first message of the new client as "V2\0\00\0"? Thanks, Yoshihiro YUNOMAE -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFC PATCH 08/11] trace-cmd: Apply the trace-msg protocol for communication between a server and clients
(2013/08/27 22:05), Steven Rostedt wrote: On Tue, 27 Aug 2013 19:23:24 +0900 Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com wrote: OK, let me check that. Even if the old server will receive V2, the server will send port numbers instead of V2 due to the old protocol. In that time, the new client will disconnect from the old server and the restarts with the old protocol. Is it OK? Yep, that's exactly what I meant ;-) I tried to implement the feature, but I found that sending just V2 from the new client is inappropriate. This is because the old server doesn't respond to the client before receiving cpu numbers, page size, and options. So, when the new client sends the first message, it should send V2\0MAGIC_NUMBER\00\0, I think. If so, the old server will understand the message as cpus=0, pagesize=MAGIC_NUMBER, options=0, and then it will send port numbers(actually \0). Note if MAGIC_NUMBER is zero, the old server will die. Can I implement the first message of the new client as V2\0MAGIC_NUMBER\00\0? Thanks, Yoshihiro YUNOMAE -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 08/11] trace-cmd: Apply the trace-msg protocol for communication between a server and clients
On Wed, 28 Aug 2013 20:30:17 +0900 Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com wrote: (2013/08/27 22:05), Steven Rostedt wrote: On Tue, 27 Aug 2013 19:23:24 +0900 Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com wrote: OK, let me check that. Even if the old server will receive V2, the server will send port numbers instead of V2 due to the old protocol. In that time, the new client will disconnect from the old server and the restarts with the old protocol. Is it OK? Yep, that's exactly what I meant ;-) I tried to implement the feature, but I found that sending just V2 from the new client is inappropriate. This is because the old server doesn't respond to the client before receiving cpu numbers, page size, and options. So, when the new client sends the first message, it should send V2\0MAGIC_NUMBER\00\0, I think. If so, the old server will understand the message as cpus=0, pagesize=MAGIC_NUMBER, options=0, and then it will send port numbers(actually \0). Note if MAGIC_NUMBER is zero, the old server will die. Can I implement the first message of the new client as V2\0MAGIC_NUMBER\00\0? If it works for both old and new server with old and new client (and all combinations) I'm fine with it. Thanks, -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFC PATCH 08/11] trace-cmd: Apply the trace-msg protocol for communication between a server and clients
(2013/08/28 23:42), Steven Rostedt wrote: On Wed, 28 Aug 2013 20:30:17 +0900 Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com wrote: (2013/08/27 22:05), Steven Rostedt wrote: On Tue, 27 Aug 2013 19:23:24 +0900 Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com wrote: OK, let me check that. Even if the old server will receive V2, the server will send port numbers instead of V2 due to the old protocol. In that time, the new client will disconnect from the old server and the restarts with the old protocol. Is it OK? Yep, that's exactly what I meant ;-) I tried to implement the feature, but I found that sending just V2 from the new client is inappropriate. This is because the old server doesn't respond to the client before receiving cpu numbers, page size, and options. So, when the new client sends the first message, it should send V2\0MAGIC_NUMBER\00\0, I think. If so, the old server will understand the message as cpus=0, pagesize=MAGIC_NUMBER, options=0, and then it will send port numbers(actually \0). Note if MAGIC_NUMBER is zero, the old server will die. Can I implement the first message of the new client as V2\0MAGIC_NUMBER\00\0? If it works for both old and new server with old and new client (and all combinations) I'm fine with it. OK, I'll submit trace-cmd patches as V2 in a few days. Thanks, Yoshihiro YUNOMAE -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 08/11] trace-cmd: Apply the trace-msg protocol for communication between a server and clients
On Tue, 27 Aug 2013 19:23:24 +0900 Yoshihiro YUNOMAE wrote: > OK, let me check that. Even if the old server will receive "V2", the > server will send port numbers instead of "V2" due to the old protocol. > In that time, the new client will disconnect from the old server and > the restarts with the old protocol. Is it OK? Yep, that's exactly what I meant ;-) -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFC PATCH 08/11] trace-cmd: Apply the trace-msg protocol for communication between a server and clients
(2013/08/27 0:11), Steven Rostedt wrote: On Mon, 26 Aug 2013 10:50:33 +0900 Yoshihiro YUNOMAE wrote: 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. That will kill an old client. Yes it only checks the first 8 bytes, but then it gets back a comma separated list of CPUs. As it uses TCP for this transaction, the unread "-v2" will end up being read as CPUs by the client. Ah, that's true. This method is inappropriate. 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. It will have to be the client that determines if the protocol is v2 or not. Basically, after receiving the "tracecmd" the client can send back "V2", and then expect the server to reply with "V2" as well. If the server does not, then it disconnects from the server and then restarts with the old protocol. OK, let me check that. Even if the old server will receive "V2", the server will send port numbers instead of "V2" due to the old protocol. In that time, the new client will disconnect from the old server and the restarts with the old protocol. Is it OK? Thanks! Yoshihiro YUNOMAE -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [RFC PATCH 08/11] trace-cmd: Apply the trace-msg protocol for communication between a server and clients
(2013/08/27 0:11), Steven Rostedt wrote: On Mon, 26 Aug 2013 10:50:33 +0900 Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com wrote: 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. That will kill an old client. Yes it only checks the first 8 bytes, but then it gets back a comma separated list of CPUs. As it uses TCP for this transaction, the unread -v2 will end up being read as CPUs by the client. Ah, that's true. This method is inappropriate. 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. It will have to be the client that determines if the protocol is v2 or not. Basically, after receiving the tracecmd the client can send back V2, and then expect the server to reply with V2 as well. If the server does not, then it disconnects from the server and then restarts with the old protocol. OK, let me check that. Even if the old server will receive V2, the server will send port numbers instead of V2 due to the old protocol. In that time, the new client will disconnect from the old server and the restarts with the old protocol. Is it OK? Thanks! Yoshihiro YUNOMAE -- Yoshihiro YUNOMAE Software Platform Research Dept. Linux Technology Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: yoshihiro.yunomae...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 08/11] trace-cmd: Apply the trace-msg protocol for communication between a server and clients
On Tue, 27 Aug 2013 19:23:24 +0900 Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com wrote: OK, let me check that. Even if the old server will receive V2, the server will send port numbers instead of V2 due to the old protocol. In that time, the new client will disconnect from the old server and the restarts with the old protocol. Is it OK? Yep, that's exactly what I meant ;-) -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 08/11] trace-cmd: Apply the trace-msg protocol for communication between a server and clients
On Mon, 26 Aug 2013 10:50:33 +0900 Yoshihiro YUNOMAE wrote: > > 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. That will kill an old client. Yes it only checks the first 8 bytes, but then it gets back a comma separated list of CPUs. As it uses TCP for this transaction, the unread "-v2" will end up being read as CPUs by the client. > > 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. > It will have to be the client that determines if the protocol is v2 or not. Basically, after receiving the "tracecmd" the client can send back "V2", and then expect the server to reply with "V2" as well. If the server does not, then it disconnects from the server and then restarts with the old protocol. > > This is new feature, so trace-cmd does not need to keep backward > compatibility. Right, the virtio-serial will noly need to be supported by the v2 protocols. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 08/11] trace-cmd: Apply the trace-msg protocol for communication between a server and clients
On Mon, 26 Aug 2013 10:50:33 +0900 Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com wrote: 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. That will kill an old client. Yes it only checks the first 8 bytes, but then it gets back a comma separated list of CPUs. As it uses TCP for this transaction, the unread -v2 will end up being read as CPUs by the client. 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. It will have to be the client that determines if the protocol is v2 or not. Basically, after receiving the tracecmd the client can send back V2, and then expect the server to reply with V2 as well. If the server does not, then it disconnects from the server and then restarts with the old protocol. Virtio-serial This is new feature, so trace-cmd does not need to keep backward compatibility. Right, the virtio-serial will noly need to be supported by the v2 protocols. -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 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? 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. 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...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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...@hitachi.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...@hitachi.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 08/11] trace-cmd: Apply the trace-msg protocol for communication between a server and clients
On Mon, 19 Aug 2013 18:46:39 +0900 Yoshihiro YUNOMAE 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. 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. If you need help in accomplishing this, I'll work with you on that. Thanks! -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 08/11] trace-cmd: Apply the trace-msg protocol for communication between a server and clients
On Mon, 19 Aug 2013 18:46:39 +0900 Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.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. 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. If you need help in accomplishing this, I'll work with you on that. Thanks! -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 08/11] trace-cmd: Apply the trace-msg protocol for communication between a server and clients
Apply trace-msg protocol for communication between a server and clients. Currently, trace-listen(server) and trace-record -N(client) operate as follows: listen to socket fd connect to socket fd accept the client send "tracecmd" +> receive "tracecmd" check "tracecmd" send cpus receive cpus <+ print "cpus=XXX" +> send pagesize | receive pagesize <+ print "pagesize=XXX" +> send option | receive option <--+ understand option send port_array +> receive port_array understand port_array send meta data receive meta data <---+ record meta data (snip) read block --- start sending trace data on child processes --- --- When client finishes sending trace data --- close(socket fd) read size = 0 close(socket fd) Currently, all messages are unstructured character strings, so server(client) using the protocol must parse the unstructured messages. Since it is hard to add complex contents in the protocol, structured binary message trace-msg is introduced as the communication protocol. By applying this patch, server and client operate as follows: listen to socket fd connect to socket fd accept the client send a connection message(MSG_TCONNECT) receive MSG_TCONNECT <+ send "tracecmd" +-MSG_RCONNECT-> receive MSG_RCONNECT check "tracecmd" send cpus,pagesize,option(MSG_TINIT) receive MSG_TINIT <---+ print "cpus=XXX" print "pagesize=XXX" understand option send port_array +--MSG_RINIT-> receive MSG_RINIT understand port_array send meta data(MSG_SENDMETA) receive MSG_SENDMETA <+ record meta data (snip) send a message to finish sending meta data | (MSG_FINMETA) receive MSG_FINMETA <-+ read block --- start sending trace data on child processes --- --- When client finishes sending trace data --- send MSG_CLOSE receive MSG_CLOSE <---+ close(socket fd)close(socket fd) By introducing trace-msg protocol, when a client tries to connect to the server, the client sends a message(MSG_TCONNECT) first. When client finishes sending trace data, the client sends a message(MSG_CLOSE). 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. Signed-off-by: Yoshihiro YUNOMAE --- Makefile |2 trace-cmd.h| 12 + trace-listen.c | 144 +- trace-msg.c| 782 trace-msg.h| 21 ++ trace-output.c |4 trace-record.c | 77 -- 7 files changed, 836 insertions(+), 206 deletions(-) create mode 100644 trace-msg.c create mode 100644 trace-msg.h diff --git a/Makefile b/Makefile index 51c6f39..cebe553 100644 --- a/Makefile +++ b/Makefile @@ -314,7 +314,7 @@ KERNEL_SHARK_OBJS = $(TRACE_VIEW_OBJS) $(TRACE_GRAPH_OBJS) $(TRACE_GUI_OBJS) \ PEVENT_LIB_OBJS = event-parse.o trace-seq.o parse-filter.o parse-utils.o TCMD_LIB_OBJS = $(PEVENT_LIB_OBJS) trace-util.o trace-input.o trace-ftrace.o \ trace-output.o trace-recorder.o trace-restore.o trace-usage.o \ - trace-blk-hack.o kbuffer-parse.o + trace-blk-hack.o kbuffer-parse.o trace-msg.o PLUGIN_OBJS = plugin_hrtimer.o plugin_kmem.o plugin_sched_switch.o \ plugin_mac80211.o plugin_jbd2.o plugin_function.o plugin_kvm.o \ diff --git a/trace-cmd.h b/trace-cmd.h index cbbc6ed..5ae5313 100644 --- a/trace-cmd.h +++ b/trace-cmd.h @@ -248,6 +248,18 @@ void tracecmd_stop_recording(struct tracecmd_recorder *recorder); void tracecmd_stat_cpu(struct trace_seq *s, int cpu); long tracecmd_flush_recording(struct tracecmd_recorder *recorder); +/* for clients */ +int tracecmd_msg_connect_to_server(int fd); +int tracecmd_msg_metadata_send(int fd, char *buf, int size); +int tracecmd_msg_finish_sending_metadata(int fd); +void tracecmd_msg_send_close_msg(); + +/* for server */ +int tracecmd_msg_set_connection(int fd); +int tracecmd_msg_initial_setting(int fd, int *cpus, int *pagesize); +int
[RFC PATCH 08/11] trace-cmd: Apply the trace-msg protocol for communication between a server and clients
Apply trace-msg protocol for communication between a server and clients. Currently, trace-listen(server) and trace-record -N(client) operate as follows: server client listen to socket fd connect to socket fd accept the client send tracecmd + receive tracecmd check tracecmd send cpus receive cpus + print cpus=XXX + send pagesize | receive pagesize + print pagesize=XXX + send option | receive option --+ understand option send port_array + receive port_array understand port_array send meta data receive meta data ---+ record meta data (snip) read block --- start sending trace data on child processes --- --- When client finishes sending trace data --- close(socket fd) read size = 0 close(socket fd) Currently, all messages are unstructured character strings, so server(client) using the protocol must parse the unstructured messages. Since it is hard to add complex contents in the protocol, structured binary message trace-msg is introduced as the communication protocol. By applying this patch, server and client operate as follows: server client listen to socket fd connect to socket fd accept the client send a connection message(MSG_TCONNECT) receive MSG_TCONNECT + send tracecmd +-MSG_RCONNECT- receive MSG_RCONNECT check tracecmd send cpus,pagesize,option(MSG_TINIT) receive MSG_TINIT ---+ print cpus=XXX print pagesize=XXX understand option send port_array +--MSG_RINIT- receive MSG_RINIT understand port_array send meta data(MSG_SENDMETA) receive MSG_SENDMETA + record meta data (snip) send a message to finish sending meta data | (MSG_FINMETA) receive MSG_FINMETA -+ read block --- start sending trace data on child processes --- --- When client finishes sending trace data --- send MSG_CLOSE receive MSG_CLOSE ---+ close(socket fd)close(socket fd) By introducing trace-msg protocol, when a client tries to connect to the server, the client sends a message(MSG_TCONNECT) first. When client finishes sending trace data, the client sends a message(MSG_CLOSE). 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. Signed-off-by: Yoshihiro YUNOMAE yoshihiro.yunomae...@hitachi.com --- Makefile |2 trace-cmd.h| 12 + trace-listen.c | 144 +- trace-msg.c| 782 trace-msg.h| 21 ++ trace-output.c |4 trace-record.c | 77 -- 7 files changed, 836 insertions(+), 206 deletions(-) create mode 100644 trace-msg.c create mode 100644 trace-msg.h diff --git a/Makefile b/Makefile index 51c6f39..cebe553 100644 --- a/Makefile +++ b/Makefile @@ -314,7 +314,7 @@ KERNEL_SHARK_OBJS = $(TRACE_VIEW_OBJS) $(TRACE_GRAPH_OBJS) $(TRACE_GUI_OBJS) \ PEVENT_LIB_OBJS = event-parse.o trace-seq.o parse-filter.o parse-utils.o TCMD_LIB_OBJS = $(PEVENT_LIB_OBJS) trace-util.o trace-input.o trace-ftrace.o \ trace-output.o trace-recorder.o trace-restore.o trace-usage.o \ - trace-blk-hack.o kbuffer-parse.o + trace-blk-hack.o kbuffer-parse.o trace-msg.o PLUGIN_OBJS = plugin_hrtimer.o plugin_kmem.o plugin_sched_switch.o \ plugin_mac80211.o plugin_jbd2.o plugin_function.o plugin_kvm.o \ diff --git a/trace-cmd.h b/trace-cmd.h index cbbc6ed..5ae5313 100644 --- a/trace-cmd.h +++ b/trace-cmd.h @@ -248,6 +248,18 @@ void tracecmd_stop_recording(struct tracecmd_recorder *recorder); void tracecmd_stat_cpu(struct trace_seq *s, int cpu); long tracecmd_flush_recording(struct tracecmd_recorder *recorder); +/* for clients */ +int tracecmd_msg_connect_to_server(int fd); +int tracecmd_msg_metadata_send(int fd, char *buf, int size); +int tracecmd_msg_finish_sending_metadata(int fd); +void tracecmd_msg_send_close_msg(); + +/* for server */ +int tracecmd_msg_set_connection(int fd); +int tracecmd_msg_initial_setting(int fd, int *cpus,
