From: Steven Rostedt <rostedt@goodmis.org>
To: Pierre Gondois <pierre.gondois@arm.com>
Cc: Linux Trace Devel <linux-trace-devel@vger.kernel.org>
Subject: Re: [PATCH v3 4/5] trace-cmd split: Enable support for buffer selection
Date: Mon, 12 Feb 2024 16:28:00 -0500 [thread overview]
Message-ID: <20240212162800.3fe15000@gandalf.local.home> (raw)
In-Reply-To: <5f983dc2-2aa2-4f4e-a1c4-ce72007e4f52@arm.com>
On Mon, 12 Feb 2024 10:11:52 +0100
Pierre Gondois <pierre.gondois@arm.com> wrote:
> Ok right. I think I got confused due to the possibility to have multiple
> output files when expanding 'trace-cmd split <TOP_COMMANDS> <INSTANCE_COMMANDS>'
Yeah, I think we got on the tangent of having split become too powerful for
one line. Having it only have one output name probably is the least
confusing. It can be called multiple times if someone wants more complex
parsing.
>
> I think the description should match this then:
> trace-cmd split [OTHER_OPTIONS] [--top [-b name]] [-o output_file] [-B instance_name [-t]]*
> [start-time [end-time]]
> # The '-t' option can only be used once per command line
>
> or:
> trace-cmd split <TOP_COMMANDS> <OUTPUT_COMMAND> <INSTANCE_COMMANDS>
>
> TOP_COMMANDS :: nil | --top TOP_PARAMS
> TOP_PARAMS :: nil | -b name
>
> OUTPUT_COMMAND :: nil | -o output_file
>
> INSTANCE_COMMANDS :: nil | -B name INSTANCE_PARAMS INSTANCE_COMMANDS
> INSTANCE_PARAMS :: nil | -t
> # INSTANCE_PARAMS can only expand to '-t' once.
>
> I'm also not sure it is necessary to have a specific order for the
> --top/-o/-B parameters. I should also work when they are unordered
> if we limit the command to one output file:
> - trace-cmd split -B foo -t --top -b old_top -o output.dat
> - trace-cmd split -o output.dat -B foo -t --top -b old_top
> - trace-cmd split -o output.dat --top -b old_top -B foo -t
> should all be equivalent.
Yeah, that's fine. Let's go with that.
-- Steve
next prev parent reply other threads:[~2024-02-12 21:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-23 13:42 [PATCH v3 0/5] trace-cmd: split: Handle splitting files with multiple instances Pierre Gondois
2024-01-23 13:42 ` [PATCH v3 1/5] trace-cmd split: Store instances in local list Pierre Gondois
2024-01-23 13:42 ` [PATCH v3 2/5] trace-cmd split: Add functions to generate temp files Pierre Gondois
2024-01-23 13:42 ` [PATCH v3 3/5] trace-cmd split: Handle splitting files with multiple instances Pierre Gondois
2024-01-24 22:35 ` Steven Rostedt
2024-01-23 13:42 ` [PATCH v3 4/5] trace-cmd split: Enable support for buffer selection Pierre Gondois
2024-01-24 22:37 ` Steven Rostedt
2024-01-25 15:16 ` Pierre Gondois
2024-01-25 16:28 ` Steven Rostedt
2024-01-25 16:51 ` Steven Rostedt
2024-01-25 17:10 ` Steven Rostedt
2024-01-26 8:54 ` Pierre Gondois
2024-02-02 2:17 ` Steven Rostedt
2024-02-05 13:38 ` Pierre Gondois
2024-02-11 23:35 ` Steven Rostedt
2024-02-12 9:11 ` Pierre Gondois
2024-02-12 21:28 ` Steven Rostedt [this message]
2024-01-23 13:42 ` [PATCH v3 5/5] trace-cmd split: Update usage Pierre Gondois
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=20240212162800.3fe15000@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=linux-trace-devel@vger.kernel.org \
--cc=pierre.gondois@arm.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).