On Wed, Mar 24, 2021 at 3:34 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> On Mon, 22 Mar 2021 11:59:35 +0200
> "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@xxxxxxxxx> wrote:
>
> > @@ -4168,7 +4167,8 @@ static void write_guest_file(struct buffer_instance *instance)
> > handle = tracecmd_get_output_handle_fd(fd);
> > if (!handle)
> > die("error writing to %s", file);
> > -
> > + if (instance->flags & BUFFER_FL_TSC2NSEC)
> > + tracecmd_set_out_clock(handle, TSCNSEC_CLOCK);
> > temp_files = malloc(sizeof(*temp_files) * cpu_count);
> > if (!temp_files)
> > die("failed to allocate temp_files for %d cpus",
> > @@ -4290,9 +4290,10 @@ static void record_data(struct common_record_context *ctx)
> > add_guest_info(handle, instance);
> > }
> >
> > - if (ctx->tsc2nsec.mult)
> > + if (ctx->tsc2nsec.mult) {
> > add_tsc2nsec(handle, &ctx->tsc2nsec);
> > -
> > + tracecmd_set_out_clock(handle, TSCNSEC_CLOCK);
> > + }
> > if (tracecmd_write_cmdlines(handle))
> > die("Writing cmdlines");
> >
>
> OK, I see why you wanted to clean up the writing of all clocks. But I
> still find that information valuable as for the reasons I stated in the
> other email. I wonder if we can still read all the clocks, parse them
> out (remove the '[' and ']') and have tracecmd_set_out_clock() still
> write them. Hmm? Or at least save them in a new option (like I save
> uname).
The TRACECMD_OPTION_TRACECLOCK option can be extended to hold the
content of the "trace_clock" file. It is an empty option now, adding
more bytes will not break the old logic.
>
> -- Steve
--
Tzvetomir (Ceco) Stoyanov
VMware Open Source Technology Center
|