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.2 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 1F90AC2B9F4 for ; Tue, 22 Jun 2021 13:58:54 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EFC8A61369 for ; Tue, 22 Jun 2021 13:58:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230212AbhFVOBJ (ORCPT ); Tue, 22 Jun 2021 10:01:09 -0400 Received: from mail.kernel.org ([198.145.29.99]:39678 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229988AbhFVOBI (ORCPT ); Tue, 22 Jun 2021 10:01:08 -0400 Received: from gandalf.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 53EE761357; Tue, 22 Jun 2021 13:58:52 +0000 (UTC) Date: Tue, 22 Jun 2021 09:58:50 -0400 From: Steven Rostedt To: Tzvetomir Stoyanov Cc: Linux Trace Devel Subject: Re: [PATCH v6 45/45] trace-cmd: Update trace.dat man page Message-ID: <20210622095850.79ed69ee@gandalf.local.home> In-Reply-To: References: <20210614075029.598048-1-tz.stoyanov@gmail.com> <20210614075029.598048-46-tz.stoyanov@gmail.com> <20210621203716.17121623@oasis.local.home> X-Mailer: Claws Mail 3.17.8 (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 Tue, 22 Jun 2021 14:05:25 +0300 Tzvetomir Stoyanov wrote: > I was thinking the same, but could not find a use case. That means to > give control to the user to decide what parts should be compressed. > This will complicate the implementation, new trace-cmd parameters > should be added. As I couldn't thought of a use case, decided to go > with the simpler approach. May be it makes sense only for the trace > data, but the metadata should be always compressed if possible. I haven't though too hard for a use case, but the problem about going with the simple approach is that if we come up with a use case, we can never implement it. I like to error on the side of flexibility at the cost of some complexity at the beginning. You may not need that flexibility for years to come, but when it happens, you'll be really glad you did it that way. When going with the simple approach, and putting yourself in a corner, you are setting yourself up for easy work now, but could potentially have a real hard time, including complete rewrites, or just giving up on features, in the future. The use case I had was not to allow users to have a lot of options, but it lets us know if we want to bother compressing everything or not. We can perhaps find that compression takes up more time, and doesn't save us anything. If we find that's the case, we can chose not to compress later. By adding a flag that tells trace-cmd if a section is compressed or not, we don't need to worry about that change. We could uncompress a section, and everything will still "just work"! -- Steve