Re: [PATCH v3 4/5] trace-cmd split: Enable support for buffer selection

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 25 Jan 2024 16:16:42 +0100
Pierre Gondois <pierre.gondois@arm.com> wrote:

> >> For example, with a trace recorded with:
> >>    $ trace-cmd record -e sched_wakeup -B switch_instance \
> >>      -e sched_switch -B timer_instance -e timer  
> > 
> > I tried this with a trace.dat file that has a instance called "tast" and it
> > didn't work. Note, the top instance had no data.
> > 
> >    $ trace-cmd split -i /work/traces/trace-tast.dat -o /tmp/trace-tast2.dat -B tast  
> 
> With this command, the expected behaviour should be:
> trace-tast2.dat:
> - Contains all the instances of the input trace-tast.dat file

Wait what? -i should *not* be used for output if -o is specified!

Now looking at it, I have a bunch of unwanted files in the /work/traces/
directory. That directory is only for traces that I took from test boxes
that I was debugging. All "split" output was suppose to go into /tmp!

> trace-tast.dat.1:
> - Contains the tast instance only, as the top instance

No, that makes no sense to me. The above is me saying:

 "I want to split out the 'tast' instance and make it the top level
 instance in trace-tast2.dat."

-i just mean "input source", and is only used if -o is not specified.

From the man page of 'trace-cmd split'

 -i file
       If this option is not specified, then the split command will look
       for the file named trace.dat. This options will allow the reading of
       another file other than trace.dat.

  -o file
       By default, the split command will use the input file name as a
       basis of where to write the split files. The output file will be the
       input file with an attached '.#\' to the end: trace.dat.1,
       trace.dat.2, etc.

           This option will change the name of the base file used.

           -o file  will create file.1, file.2, etc.


> 
> If the 2 files don't match the above description, there is an issue.

No, it shouldn't do that. It did match your description, but I never
noticed because it was writing files into my "input" directory, which I was
never looking at. :-(

Using your method means we can't use -i for just an input source.

> 
> ---
> 
> Otherwise, I believe the command line should be parsed as:
> 1-
> Select all the desired instances with -B or --top,
> the first instance is placed as the top instance.
> 2-
> When parsing a '-o', select all the previously selected instances and
> put them in the output file.



> 3-
> Start all over again from 1-. If there is no output file described
> at the end of the command line, place the result in [input_file].dat.X

No. input_file should only be used if no output file is specified. If it
had done that before your patches, it was a bug and needs to be fixed.

> 
> So placing the output file at the end of the command line is important
> here. If you think the command line should be parsed another way, please
> let me know,

Now, placement can be important, and perhaps we can use the input_file as
default as if the output file is specified later. I was thinking of doing
this as a separate patch, but if we do allow for multiple output files,
then we can have the commands to do for those files after that.

That is if we have:

  trace-cmd split -i trace.dat --top -o trace-foo.dat -B foo -o trace-bar.dat -B bar

It could then split out the top instance by itself in trace.dat.1, have
trace-foo.dat have the 'foo' instance as its main instance, and
trace-bar.dat have 'bar' instance as its main instance. So order would matter then.

But if nothing is between -i and -o, then nothing should be done against
-i. That is, if the above was:

  trace-cmd split -i trace.dat -o trace-foo.dat -B foo -o trace-bar.dat -B bar

(removed --top) then it would not create the trace.dat.1 file.

And we need to update the man pages and possibly the usage to explicitly
state how order matters.

-- Steve