Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1243388pxj; Fri, 4 Jun 2021 09:23:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzcKRyqA2aMEfMc2toJorKqSjQ8JJNpgmN6yKm16kZGDM+48IcUMD7eVfb9sPBhX7+KlN6Z X-Received: by 2002:a17:906:f2d6:: with SMTP id gz22mr2245978ejb.137.1622823834649; Fri, 04 Jun 2021 09:23:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622823834; cv=none; d=google.com; s=arc-20160816; b=cwoOt011ZJyM7Mq0ldFCuKyTfxgkBbXzGm39lCOdojpZxi/uDJ/v86LsmkrVLASYYe 3+3dsdqGA+ed/mSq95zs6x06jcS08Gg1MiTXugxxGny4gX3KeVAunowbCevx+esJClTd q5rblA1wsp2oUPjlQiE0ubtig1HAnoBUfs5McJWi72UCf6tOGgFqLymmvwuNxX1oUKPn JU4fLVItCRouXoQdg9+S9lJwRhEB1crUlZsRrRfsjaKljm16R5SE7cbKJMwUMcp26tYO zssbHW8TK5sGmTFQWo7+GUl8PzKSCUVN9Gk7NKt81IdhlcIkS1ycQJoVBqvpZZd+pirL Grog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=VIVFirr99eteNTBGcnRkWv9HxyApAO5apB9ba1cLcLI=; b=gAV4kV+v1Biixl/UFvyHu4idTrqeDuhWoaaT5mg8jBEqbCDkO9cD+BgQpXTA8Wo15C 6pazHrFhNyW0ggWxYGKOiHRDLg/+oczbVQkUVNtckvLTIVLKS1UQdwibhPnti/h4L8iX 7aLlctYluOanlv/+5Bazn0La5dajBzSoCHVIkMzYUYg8xBAX5IVvxwJyanZ1UNoEA89w 74+DKJksoCQvDM06GewrVHXNEtQ9ZjiVD78hW8v9CkqaQN7hIQUZtKNt+Hbh5lN7maQb Tors8TQbPrTBJcmWXBtik7YbuKCdRtLgLG6lzSXhtTSmSCuKnVi2Xz9QceX9IIhvJksc /+Og== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e20si5234225ejd.727.2021.06.04.09.23.30; Fri, 04 Jun 2021 09:23:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230080AbhFDQXS (ORCPT + 99 others); Fri, 4 Jun 2021 12:23:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:41442 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229746AbhFDQXS (ORCPT ); Fri, 4 Jun 2021 12:23:18 -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 52FBC61405; Fri, 4 Jun 2021 16:21:30 +0000 (UTC) Date: Fri, 4 Jun 2021 12:21:28 -0400 From: Steven Rostedt To: Joe Perches Cc: Daniel Bristot de Oliveira , linux-kernel@vger.kernel.org, Phil Auld , Sebastian Andrzej Siewior , Kate Carcia , Jonathan Corbet , Ingo Molnar , Peter Zijlstra , Thomas Gleixner , Alexandre Chartre , Clark Willaims , John Kacur , Juri Lelli , linux-doc@vger.kernel.org Subject: Re: [PATCH V3 7/9] tracing: Add __print_ns_to_secs() and __print_ns_without_secs() helpers Message-ID: <20210604122128.0d348960@oasis.local.home> In-Reply-To: <1e068d21106bb6db05b735b4916bb420e6c9842a.camel@perches.com> References: <2c59beee3b36b15592bfbb9f26dee7f8b55fd814.1621024265.git.bristot@redhat.com> <20210603172902.41648183@gandalf.local.home> <1e068d21106bb6db05b735b4916bb420e6c9842a.camel@perches.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-kernel@vger.kernel.org On Thu, 03 Jun 2021 21:19:50 -0700 Joe Perches wrote: > If tracing cleanups for trace_events.h are being done, perhaps > another bit of untidiness is the macro definition and uses of > __assign_str. This isn't a tracing cleanup, but adding new functionality. That said, > > $ git grep -w -1 __assign_str include/trace/trace_events.h > include/trace/trace_events.h- > include/trace/trace_events.h:#undef __assign_str > include/trace/trace_events.h:#define __assign_str(dst, src) \ > include/trace/trace_events.h- strcpy(__get_str(dst), (src) ? (const char *)(src) : "(null)"); > > Its definition has a semicolon as do most uses but a dozen handfuls of > other uses do not have a semicolon. It'd be more consistent to add a > semicolon to the uses without them and when done treewide, then remove > the semicolon from the macro declaration. I have no problem taking a clean up patch that adds semicolons to all use cases of "__assign_str()" and ever remove the one from where it is defined. As long as it doesn't break any builds, I'm fine with that. -- Steve