From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C1EA6C433DB for ; Wed, 24 Mar 2021 00:53:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 85944619E8 for ; Wed, 24 Mar 2021 00:53:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233533AbhCXAwh (ORCPT ); Tue, 23 Mar 2021 20:52:37 -0400 Received: from mail.kernel.org ([198.145.29.99]:53972 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233460AbhCXAwI (ORCPT ); Tue, 23 Mar 2021 20:52:08 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D20F2619E5; Wed, 24 Mar 2021 00:52:07 +0000 (UTC) Date: Tue, 23 Mar 2021 20:52:05 -0400 From: Steven Rostedt To: "Tzvetomir Stoyanov (VMware)" Cc: linux-trace-devel@vger.kernel.org Subject: Re: [PATCH v2 03/18] trace-cmd: Save only the selected clock in the trace.dat file Message-ID: <20210323205205.192e62ae@oasis.local.home> In-Reply-To: <20210322095945.259300-4-tz.stoyanov@gmail.com> References: <20210322095945.259300-1-tz.stoyanov@gmail.com> <20210322095945.259300-4-tz.stoyanov@gmail.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-trace-devel@vger.kernel.org On Mon, 22 Mar 2021 11:59:30 +0200 "Tzvetomir Stoyanov (VMware)" wrote: > Trace clock, used for curent trace sessions is saved in the trace.dat > file. This information is used when displaying timestamps of the events. > However, only the selected clock is needed. > A new API is added: > tracecmd_set_out_clock(); > that can be used to set the trace clock on the output handle. > There's no reason not to have the other clocks in the file. I would rather keep them as it doesn't hurt to have them right? The reason for keeping them is when a customer sends you a trace.dat file (from commands you ask them to run), you can use the trace.dat file to see what other clocks they have configured in case you want to have them try another clock in their next recording. Extra data about the system the trace.dat file was run on is always a plus. -- Steve