From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 73BFE42219; Fri, 1 Sep 2023 04:32:55 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 707C1402B6; Fri, 1 Sep 2023 04:32:55 +0200 (CEST) Received: from mail-ua1-f46.google.com (mail-ua1-f46.google.com [209.85.222.46]) by mails.dpdk.org (Postfix) with ESMTP id 6F3F4402B8 for ; Fri, 1 Sep 2023 04:32:53 +0200 (CEST) Received: by mail-ua1-f46.google.com with SMTP id a1e0cc1a2514c-7a50bd29064so552036241.3 for ; Thu, 31 Aug 2023 19:32:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1693535573; x=1694140373; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=vPxB5qJdolh3LTVM2A/Tlhk9DPWcPSka0uMUJak7PAo=; b=D1hdk6sg3clk0DHPKqiqiWkn/jnpyseDODNvBf4VDiLXk1Fv/Z0RmLXCxU9NVeQa3t MOhQwbDde6bL/jpS3uEmdwOdIM/GYUDGnYsX9mMFZLJaCUVy0XE5qdy8GkwtUAGlLtC6 9+TaEkPCTLeaPIQjvrbZdEB3oH8h5BU5N7fGopjVumGI4Qwrr7I5jtSlD3XrvZILB+oC pvrokCuFyS6Oc80HZFML0NHDIwKAEIwKb8kbSAFO2ToGiP/DGE7OH7vzwh1LOe7TTgQ9 qLLwQYQxtXB9lEuzZfbgKdvzj93eVxEsmRNB1t+XtbYt6eKER9l1YFz53tbsBWp5v4gd 6+Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693535573; x=1694140373; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vPxB5qJdolh3LTVM2A/Tlhk9DPWcPSka0uMUJak7PAo=; b=lckJjPfuuX0X7fSOUlRIrAVWtVrFnMoQGyLbDhBfUCeVKnPTuqpIqpwcZjtCHi4Z3S fztfcd5N2EICAMrIw0qYc/ngfGn4E5Cd6tfgxQlV2qLsnuoOCkzKzWJ+cYL/86y09MHx TNH4zEBSwBru8bChIt/G37tp+Nek0+njqRn2poziQKQcBp5nQH0mXhcXCVoh/VloCZCz DBj7MmyYrdqkOvfo9riiOPOOnd5tw4LWcNadKx2YZIMpI+j1CtqbgMMpL5TnqEnAVbcB mCh5ua2wOcLnl0d5fL4jIPn/nhmx9zC4mYtL+oJSc127omfGC5+KfuRb8hCmauNjl5XH Z/TA== X-Gm-Message-State: AOJu0YyCGqKMqdA3W5RWf6Rw/H0gui2z1H/EcY7wG5c6rdbLBzbjl8Nx i1525yQhcl58GMNgdlwEk93VF5L6lYkcFp6o22g= X-Google-Smtp-Source: AGHT+IGTavNnjLmdf38JI2xBbYwu5sYMf6iHi5rs/b50nWsrba+IeSlokP4tOUXXvddGs9etbxHFgbSyvUJ6JCrLdEU= X-Received: by 2002:a05:6102:3005:b0:44e:9f7b:9073 with SMTP id s5-20020a056102300500b0044e9f7b9073mr1274458vsa.2.1693535572684; Thu, 31 Aug 2023 19:32:52 -0700 (PDT) MIME-Version: 1.0 References: <20230303155811.2751210-1-adwivedi@marvell.com> <98CBD80474FA8B44BF855DF32C47DC35D87B25@smartserver.smartshare.dk> <3574329.R56niFO833@thomas> <98CBD80474FA8B44BF855DF32C47DC35D87B5D@smartserver.smartshare.dk> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D87B5D@smartserver.smartshare.dk> From: Jerin Jacob Date: Fri, 1 Sep 2023 08:02:26 +0530 Message-ID: Subject: Re: [EXT] Re: [PATCH v5 1/1] devtools: add tracepoint check in checkpatch To: =?UTF-8?Q?Morten_Br=C3=B8rup?= Cc: Thomas Monjalon , Ankur Dwivedi , Stephen Hemminger , Jerin Jacob Kollanukkaran , dev@dpdk.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Thu, Aug 31, 2023 at 12:08=E2=80=AFAM Morten Br=C3=B8rup wrote: > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > Sent: Wednesday, 30 August 2023 18.24 > > > > 21/08/2023 16:46, Morten Br=C3=B8rup: > > > > From: Ankur Dwivedi [mailto:adwivedi@marvell.com] > > > > Sent: Monday, 21 August 2023 15.54 > > > > In general, I wonder how much the check is useful compared to the > > complexity. > > > > > > > The bigger question is: Do we really want to change tracepoints in > > functions from opt-in to opt-out? > > > > Yes that's the question: should traces be mandatory in some libs? > > > > > In my opinion, opt-in for trace is more appropriate. > > > > There was some work to add traces everywhere in few libs, so why not > > maintaining this state? > > I still think it's a silly and burdening requirement, but I'm not against= it for the libs where it is already a de facto standard. > > > I can imagine similar requirements regarding logging, telemetry and dump = functions being imposed on select libs. > > Perhaps we should also require that new libs implement all four types of = instrumentation, to ensure that only high quality (i.e. fully instrumented)= libs are accepted into DPDK. IMO, There is a lot of effort to put trace points to existing libraries, without these check, soon the disparity shows up when someone adds new APIs to library and forget to add trace points. It is pretty easy to add trace point and there are a lot of references, so I don't think there is burden for a developer comparing to the effort of adding a new API. Most of the time, contributors forgets to add trace point because there is no automatic way to find it. Also, additional git commits are needs if some decide to add it later. No strong opinion, If not find not useful, we could mark this patch is not appliable. Keeping the patch is limbo state is the issue. It is already reached to v5. So please decide one way or another. > > > > I don't really like adding a skip list as one more burden for future > > authors. > > If the warning omitted from checkpatches refers to the skip list and its = location, it is relatively easy for developers to manage. > > And reviewers will notice if new functions have been added to the skip li= st, indicating that trace has been omitted. So there are also advantages to= the skip list. >