On Thu, 25 Jan 2024 16:16:42 +0100
Pierre Gondois <pierre.gondois@xxxxxxx> 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
|