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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E85CFE8FDBF for ; Wed, 4 Oct 2023 01:06:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=fsx5Y6YxksdsKolmmnYeO4nzZfdYn6iCsUs0EHyNaaA=; b=XGC6jpQMvFlPGWdva9x15CIRiC b3zLuNwRl97v14/6GF5NcDYfb3gtUWy62kwzt3iRdLRz7x40AbhiPLqDKAAIBRtUO0j10y/yPzXq2 qUJ3oYRxO3Ge1H++Acn3gqEdvObGRxX64dMm5Nefc/SN5BC3BhlUiVQugP9HKfWb8rV9YHTXaGbVm xHOtGgrXaM1p/RvL88NxCylwGbA3Fza76U70nkp1+TNC8DtvyvPlsGnHgmlFHXI9qVuol2tLXaYMm hl3JgUry+jtpOjJHpe6z02fXLYpzs7UDwSmM1AYJc3GvWMMXDBwROqfc2ZUC+n4KKUi3H8Lyjw4lF JoP3jBZQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qnqL6-00FhKD-1H; Wed, 04 Oct 2023 01:06:12 +0000 Received: from mail-ua1-x935.google.com ([2607:f8b0:4864:20::935]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qnqL0-00FhJ9-09 for linux-arm-kernel@lists.infradead.org; Wed, 04 Oct 2023 01:06:10 +0000 Received: by mail-ua1-x935.google.com with SMTP id a1e0cc1a2514c-7abda795363so742933241.0 for ; Tue, 03 Oct 2023 18:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1696381564; x=1696986364; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=FD7N4+ki8yTbIdFjxebxQX9Pl+69rX6n0uIJQxEwL/U=; b=dRNbsIXWIb/c7w8qW4IRqPzPxmblLc6VB6kAKO6Lj6ruH3DiM4/lP9Vqcbr5OnQq3N kzBu4eTP/PUHBe0b1H+EHMCUgxtyqRsGgDxBQ3dP1u9+EuC2+j1+AmVdJGIlvTEdPzf6 nZ5ewSXRKaLweV4cklJuEJNbEeqA9r7zGGiTYkbrYys8cmZxDmThEv2eyHGid8RIW6uS u5UhfbPDcW/L7146B3H/ox4PCcr6qtqP95FLKvzn9AJOaqp1ZhqpZ+w+ArsTLUL5WNuA 1j+JJ92qou/BSGnTduFBANhMmNFaKrkfwc3b2kznRhMSudi4o2wRh2DdcTsTEKZe8JiJ +9hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696381564; x=1696986364; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=FD7N4+ki8yTbIdFjxebxQX9Pl+69rX6n0uIJQxEwL/U=; b=b7NiF3ZjDc5TAm2eG73OANOfKWNfxjxHgicQbEcYkdvbZa6RNwVMQMlk3RsCvFgSCq ZSZk0mCW/5+W1CWSZHHqBv0DMP4TJiXFIKR0G9q4s5Nz97DLNu7x++mEk4TlfRpqrTVy 3+DH8gS3rMYhyzmwh6aJwTivs5ZiedRJQBW5VHGUp90ziFuZBQOnky0iTsnuuN6o+Smf 4nW6FBOQXeyNGTXqOsxostDoovjIESGJhz2l0d3jYLq/c1CXfyQV6B48gXkntl/uYEhe aZ8lLTJ0caL4AUS1izhCHndmZatWxiEFJndrJ/JehPpGh/mmzXs/DZSLUJMkbJi9NnRV wSWA== X-Gm-Message-State: AOJu0YwvMgZBztLKxcvd4i7OzwKV9R2BAszVy2qpfMjAmZH6Mw1p6U4B mxxv5oTm4HB6aPirlHcHyAAnsJ3TxDPxUZpYKuw= X-Google-Smtp-Source: AGHT+IGYmIVwKRybktecfaCThlChpL8Li43s8SGPeblCnhS/dSopbmKh5eEzTeCOe+/o6Pgb7hDS5g== X-Received: by 2002:a67:f65a:0:b0:44d:3f96:6c61 with SMTP id u26-20020a67f65a000000b0044d3f966c61mr895407vso.30.1696381563938; Tue, 03 Oct 2023 18:06:03 -0700 (PDT) Received: from fedora (072-189-067-006.res.spectrum.com. [72.189.67.6]) by smtp.gmail.com with ESMTPSA id h1-20020ab04701000000b007aba00406a4sm369973uac.7.2023.10.03.18.06.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 03 Oct 2023 18:06:03 -0700 (PDT) Date: Tue, 3 Oct 2023 21:06:00 -0400 From: William Breathitt Gray To: Fabrice Gasnier Cc: lee@kernel.org, alexandre.torgue@foss.st.com, linux-iio@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/8] tools/counter: add a flexible watch events tool Message-ID: References: <20230829134029.2402868-1-fabrice.gasnier@foss.st.com> <20230829134029.2402868-4-fabrice.gasnier@foss.st.com> <7aa66ac8-eceb-2f6e-960b-2c4dac9f595e@foss.st.com> MIME-Version: 1.0 In-Reply-To: <7aa66ac8-eceb-2f6e-960b-2c4dac9f595e@foss.st.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231003_180606_176252_3ACF9441 X-CRM114-Status: GOOD ( 39.03 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0076545436004447863==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============0076545436004447863== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jZtSijHBWetMsQRX" Content-Disposition: inline --jZtSijHBWetMsQRX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 19, 2023 at 05:37:34PM +0200, Fabrice Gasnier wrote: > On 9/17/23 21:07, William Breathitt Gray wrote: > > On Tue, Aug 29, 2023 at 03:40:24PM +0200, Fabrice Gasnier wrote: > >> This adds a new counter tool to be able to test various watch events. > >> A flexible watch array can be populated from command line, each field > >> may be tuned with a dedicated command line argument. > >> Each argument can be repeated several times: each time it gets repeate= d, > >> a corresponding new watch element is allocated. > >> > >> It also comes with a simple default watch (to monitor overflows), used > >> when no watch parameters are provided. > >> > >> The print_usage() routine proposes another example, from the command l= ine, > >> which generates a 2 elements watch array, to monitor: > >> - overflow events > >> - capture events, on channel 3, that reads read captured data by > >> specifying the component id (capture3_component_id being 7 here). > >> > >> Signed-off-by: Fabrice Gasnier Fabrice, Sorry for the delay, I'm currently working through my backlog. I see you have already submitted a version 2 of this patchset, so I'll continue my review there but I do want to make some direct replys here below as well. > > This is a new tool, so would you add a MAINTAINERS entry for the > > counter_watch_events.c file? >=20 > I haven't thought about it. > I can add a MAINTAINERS entry, yes! > Who would you suggest ? Typically the author of the initial patch will also maintain what they are introducing, but an alternative person is acceptable to serve as maintainer if that's the plan that's agreed upon. I assume you're introducing this tool because you're using it internally at ST for testing, so I suppose the intention is not to get this merged upstream just to abandon it (i.e. you intend to keep using and improving it). Is the plan for you to maintain this utility, or is someone else at ST interested in it? > >> + } > >> + > >> + /* fallback to number */ > >=20 > > I'm not sure it makes sense to support numbers. Although it's true that > > the component type, component scope, and event type are passed as __u8 > > values, users are expected to treat those values are opaque and pass > > them via the respective enum constants. Since we don't guarantee that > > the specific enum constant values will remain consistent between kernel > > versions, I don't think it's a good idea to give to users that sort of > > implication by allowing them to use raw numbers for configuration > > selection. >=20 > Ack, I can remove this. >=20 > I'm a bit surprised by this statement. I may be wrong... I'd expect a > userland binary to be compatible when updating to a newer kernel: e.g. > user API (ABI?) definitions to be stable (including enum constants) ? I was wrong in my previous reply. You're absolutely correct[^1] that userspace ABI must be consistent ("Breaking user programs simply isn't acceptable"[^2]) so the specific values must remain the same between kernel versions. Regardless, I don't think raw numbers provide much benefit for the use-case of this particular utility; users are testing watch configurations for a particular device, not the specific constant values in the data structures. So in the end I still think the raw numbers code path should be removed. [^1] Well technically Linux kernel ABI README documentation file (Documentation/ABI/README) states that backwards compatibility for stable interfaces is only guaranteed for at least 2 years, but in practice we strive to never change the user-facing ABI. [^2] https://yarchive.net/comp/linux/gcc_vs_kernel_stability.html William Breathitt Gray --jZtSijHBWetMsQRX Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQSNN83d4NIlKPjon7a1SFbKvhIjKwUCZRy6eAAKCRC1SFbKvhIj K9STAP95tTRE+0GzRVXB8MfYNUgv5OwuwuDTLlkR6iV5UAPp3gEA1+ZCNsosBzzF Lbr/PCTCJRifx7T+S4h36fLilUjYaAE= =C8xr -----END PGP SIGNATURE----- --jZtSijHBWetMsQRX-- --===============0076545436004447863== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============0076545436004447863==--