From: Slavomir Kaslev <kaslevs@vmware.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "linux-trace-devel@vger.kernel.org" <linux-trace-devel@vger.kernel.org>
Subject: Re: [RFC PATCH v8 05/13] trace-cmd: Add TRACE_REQ and TRACE_RESP messages
Date: Tue, 12 Mar 2019 18:48:28 +0000 [thread overview]
Message-ID: <CAE0o1NtQE_Uux++2TRD0G+B4BY09Cwr6-qa84r4Dt3Os-hzyDw@mail.gmail.com> (raw)
In-Reply-To: <20190222160929.776ac227@gandalf.local.home>
On Fri, Feb 22, 2019 at 11:09 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Fri, 22 Feb 2019 20:05:31 +0200
> Slavomir Kaslev <kaslevs@vmware.com> wrote:
>
> > +static int make_trace_resp(struct tracecmd_msg *msg,
> > + int page_size, int nr_cpus, unsigned int *ports)
>
> I wonder if we should just have a generic "argc"/"argv" protocol to
> send dynamic amounts of data, and not have specific dynamic messages?
>
> Perhaps pass the numbers as ASCII? And then converted them at the other
> end. We need to handle ntoh anyway, so a conversion (albeit a fast one)
> is probably done anyway.
>
> We could send:
> int argc = 6;
> char **argv = { "4096", "16", "33445", "33446", "33448", "33449" };
>
> Or, if you are not comfortable with sending ASCII and converting, what
> about have a specific "sending an array of numbers"?
>
> int argc = 6;
> int *argv = { 4096, 16, 33445, 33446, 33448, 33449 };
>
> Thoughts?
I don't see any drawbacks of this approach (modulo a bit of
arithmetic). I implemented it the way it is following how the listener
is sending port numbers back to the recording process.
Should we also switch the listener to use the same encoding of ports
with protocol V3 before the next release?
How about options (which is the only other non-text use of the
variable buffer part of messages)? Currently the only option in use is
MSGOPT_USETCP and can become simply "tcp" on the wire.
We can then have a convention that the buffer at then end of messages
is always text and drop the second union in tracecmd_msg.
-- Slavi
>
> -- Steve
>
> > +{
> > + int ports_size = nr_cpus * sizeof(*msg->port_array);
> > + int i;
> > +
> > + msg->hdr.size = htonl(ntohl(msg->hdr.size) + ports_size);
> > + msg->trace_resp.cpus = htonl(nr_cpus);
> > + msg->trace_resp.page_size = htonl(page_size);
> > +
> > + msg->port_array = malloc(ports_size);
> > + if (!msg->port_array)
> > + return -ENOMEM;
> > +
> > + for (i = 0; i < nr_cpus; i++)
> > + msg->port_array[i] = htonl(ports[i]);
> > +
> > + return 0;
> > +}
> > +
> > +int tracecmd_msg_send_trace_resp(struct tracecmd_msg_handle *msg_handle,
> > + int nr_cpus, int page_size,
> > + unsigned int *ports)
> > +{
> > + struct tracecmd_msg msg;
> > + int ret;
> > +
> > + tracecmd_msg_init(MSG_TRACE_RESP, &msg);
> > + ret = make_trace_resp(&msg, page_size, nr_cpus, ports);
> > + if (ret < 0)
> > + return ret;
> > +
> > + return tracecmd_msg_send(msg_handle->fd, &msg);
> > +}
> > +
> > +int tracecmd_msg_recv_trace_resp(struct tracecmd_msg_handle *msg_handle,
> > + int *nr_cpus, int *page_size,
> > + unsigned int **ports)
> > +{
> > + struct tracecmd_msg msg;
> > + ssize_t buf_len;
> > + int i, ret;
> > +
> > + ret = tracecmd_msg_recv(msg_handle->fd, &msg);
> > + if (ret < 0)
> > + return ret;
> > +
> > + if (ntohl(msg.hdr.cmd) != MSG_TRACE_RESP) {
> > + ret = -ENOTSUP;
> > + goto out;
> > + }
> > +
> > + buf_len = ntohl(msg.hdr.size) - MSG_HDR_LEN - ntohl(msg.hdr.cmd_size);
> > + if (buf_len <= 0 ||
> > + buf_len != sizeof(*msg.port_array) * ntohl(msg.trace_resp.cpus)) {
> > + ret = -EINVAL;
> > + goto out;
> > + }
> > +
> > + *nr_cpus = ntohl(msg.trace_resp.cpus);
> > + *page_size = ntohl(msg.trace_resp.page_size);
> > + *ports = calloc(*nr_cpus, sizeof(**ports));
> > + if (!*ports) {
> > + ret = -ENOMEM;
> > + goto out;
> > + }
> > + for (i = 0; i < *nr_cpus; i++)
> > + (*ports)[i] = ntohl(msg.port_array[i]);
> > +
> > + msg_free(&msg);
> > + return 0;
> > +
> > +out:
> > + error_operation(&msg);
> > + if (ret == -EOPNOTSUPP)
> > + handle_unexpected_msg(msg_handle, &msg);
> > + msg_free(&msg);
> > + return ret;
> > +}
>
next prev parent reply other threads:[~2019-03-12 18:48 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-22 18:05 [RFC PATCH v8 00/13] Add VM kernel tracing over vsockets and FIFOs Slavomir Kaslev
2019-02-22 18:05 ` [RFC PATCH v8 01/13] trace-cmd: Minor cleanup in tracecmd_start_recording() Slavomir Kaslev
2019-02-22 18:05 ` [RFC PATCH v8 02/13] trace-cmd: Minor cleanup in print_stat() Slavomir Kaslev
2019-02-22 18:05 ` [RFC PATCH v8 03/13] trace-cmd: Detect if vsockets are available Slavomir Kaslev
2019-02-22 18:05 ` [RFC PATCH v8 04/13] trace-cmd: Add tracecmd_create_recorder_virt function Slavomir Kaslev
2019-02-22 18:05 ` [RFC PATCH v8 05/13] trace-cmd: Add TRACE_REQ and TRACE_RESP messages Slavomir Kaslev
2019-02-22 21:09 ` Steven Rostedt
2019-03-12 18:48 ` Slavomir Kaslev [this message]
2019-03-12 19:18 ` Steven Rostedt
2019-02-22 18:05 ` [RFC PATCH v8 06/13] trace-cmd: Add buffer instance flags for tracing in guest and agent context Slavomir Kaslev
2019-02-22 18:05 ` [RFC PATCH v8 07/13] trace-cmd: Add VM kernel tracing over vsockets transport Slavomir Kaslev
2019-03-12 19:23 ` Steven Rostedt
2019-03-12 23:07 ` Steven Rostedt
2019-02-22 18:05 ` [RFC PATCH v8 08/13] trace-cmd: Use splice(2) for vsockets if available Slavomir Kaslev
2019-02-22 18:05 ` [RFC PATCH v8 09/13] trace-cmd: Add `trace-cmd setup-guest` command Slavomir Kaslev
2019-02-22 18:05 ` [RFC PATCH v8 10/13] trace-cmd: Try to autodetect number of guest CPUs in setup-guest if not specified Slavomir Kaslev
2019-02-22 18:05 ` [RFC PATCH v8 11/13] trace-cmd: Add setup-guest flag for attaching FIFOs to the guest VM config Slavomir Kaslev
2019-02-22 18:05 ` [RFC PATCH v8 12/13] trace-cmd: Add splice() recording from FIFO without additional pipe buffer Slavomir Kaslev
2019-02-22 18:05 ` [RFC PATCH v8 13/13] trace-cmd: Add VM tracing over FIFOs transport Slavomir Kaslev
2019-03-12 19:28 ` Steven Rostedt
-- strict thread matches above, loose matches on Subject: below --
2019-04-02 13:42 [RFC PATCH v8 00/11] Add VM kernel tracing over vsockets and FIFOs Slavomir Kaslev
2019-04-02 13:42 ` [RFC PATCH v8 05/13] trace-cmd: Add TRACE_REQ and TRACE_RESP messages Slavomir Kaslev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAE0o1NtQE_Uux++2TRD0G+B4BY09Cwr6-qa84r4Dt3Os-hzyDw@mail.gmail.com \
--to=kaslevs@vmware.com \
--cc=linux-trace-devel@vger.kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).