Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp6897093rdb; Fri, 15 Dec 2023 11:08:49 -0800 (PST) X-Google-Smtp-Source: AGHT+IGzAsdUf4Lg00snMSB9/L8dg8ckCVGFoXLfOzd/VbAVBC5nKEPn2a0eAPsdH4BbcRJo9O+e X-Received: by 2002:a05:622a:155:b0:425:4042:f45a with SMTP id v21-20020a05622a015500b004254042f45amr16836503qtw.62.1702667329221; Fri, 15 Dec 2023 11:08:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1702667329; cv=none; d=google.com; s=arc-20160816; b=nNTZsMrcSqTwzjc8xIBLrce9xsdGZrNdI0pUa9fprbSWLtEsqOkIcImc6KA5oFsm9d Ml5w5yFTFhvlAEpbTixeATPnuwuCUJWRAEdqBMEf2SOGcvTueshkPyHH8O3dusZMzL+j cDThYb8Qq3m2U4sBM0pojN1F7572ix0D7ce8AL/tjeTCEx5/123X8E57Bz05KMM77FwH zI8KJuUslxn4GiqKOF7mJWeYTvbUqrWhLuf9lMTQTvaeejG4mt2AuGKFFrKBqDFHSStf oKJtcA5tkh3MFOfarPERQh0FcW/MIf+4X3Z+mG+ws8km1bnDf4kKS7oT5hELFbfXnYsw Qihw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id:dkim-signature; bh=u7CzcLHx4CYZY91DqTGp3fuHUX+W7xdUd0DiVD1awY4=; fh=6+dHPNKjdDTOa3r4J0IsgUv5o+9uG7i49KP+T0YP/bs=; b=hQPypJSF7X5oWZ8c0sXjTRmBSUY13pleAOuLrEkbgz1y0G0k9maj2JSv5X6yQjOJ1R 3yjJoUMR7E8ChW+7vdoL0I7VvUMrkQdQpDpPfmP6//1d187eeV4JsywgDwV74zJIxGLN jBqb3yIdmBmt0gHlRvVyKe17T7zjZ9K+I2KvH1oC3TBTczRQwfLvva1YCKQRqhTuhVHz O4Gp3tq5mv7ye2+g9AVTJJeNuFHO8LdNP3Y4o+PuPdMutCrCjP2CJ8mp4tdsDPAv3DXn /I4kg9r3hNC1sBQrOYZfiWyE57cxyiFIfWjo97VoPKhWIjyoi1ElTyrBhEIPX1cTWqAJ 4SWg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@efficios.com header.s=smtpout1 header.b=RROwbnbo; spf=pass (google.com: domain of linux-kernel+bounces-1550-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-1550-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id jx9-20020a05622a810900b0042548953dffsi16773251qtb.698.2023.12.15.11.08.49 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 Dec 2023 11:08:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-1550-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; dkim=pass header.i=@efficios.com header.s=smtpout1 header.b=RROwbnbo; spf=pass (google.com: domain of linux-kernel+bounces-1550-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-1550-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=efficios.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id EB8521C23C28 for ; Fri, 15 Dec 2023 19:08:48 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 70FFB3FB28; Fri, 15 Dec 2023 19:08:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=efficios.com header.i=@efficios.com header.b="RROwbnbo" X-Original-To: linux-kernel@vger.kernel.org Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BA4D33010B; Fri, 15 Dec 2023 19:08:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=efficios.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=efficios.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1702667320; bh=UATp6Ljlid4diMibXymVZZ5Z3BZo2w0Vii6FCR1FX7I=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=RROwbnbo2Bn6bTL6jOB+lfQg4ood193tPYpXkK7B+8tHpGSYiueXxV7u0hZu95quY doJwFvj3s+NOV1T/5NbX5GWOkzp52/Cb5VUyBJx5Rh5V2fq7089hAfsmaPFunSmsMR LiyKYjJNz07AN7JJwHkmuamNYOrdq1W38oDAfzHkXZ52qpKRSYhbjIoyaq8fMXQbdA uDKq2VfXcOGxyjklyMJtesJwO6bT2He3bmzspfuY93vgsPdrymSBH8Fr0gbDqdqFFz pDe1PO53JQYv4mnkWQxBEd0mqASUKKF0KQR+vCRv36Twfjo2tUt6itA8e80q4LO4jQ DPUTAzZT47XxQ== Received: from [172.16.0.134] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4SsJfJ36PXzH29; Fri, 15 Dec 2023 14:08:40 -0500 (EST) Message-ID: <368d36b2-e5ea-46d4-b214-6d04cf20685a@efficios.com> Date: Fri, 15 Dec 2023 14:08:40 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] tracing: Add disable-filter-buf option Content-Language: en-US To: Steven Rostedt Cc: LKML , Linux trace kernel , Masami Hiramatsu , Mark Rutland References: <20231215102633.7a24cb77@rorschach.local.home> <21936075-3858-446a-9391-a38e8d8968e7@efficios.com> <20231215120417.567d5ea4@rorschach.local.home> <20231215123458.63f57238@rorschach.local.home> <20231215134335.2388aba5@rorschach.local.home> From: Mathieu Desnoyers In-Reply-To: <20231215134335.2388aba5@rorschach.local.home> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2023-12-15 13:43, Steven Rostedt wrote: > On Fri, 15 Dec 2023 13:25:07 -0500 > Mathieu Desnoyers wrote: >> >> I am not against exposing an ABI that allows userspace to alter the >> filter behavior. I disagree on the way you plan to expose the ABI. > > These are no different than the knobs for sched_debug These are very much different. The sched features are enabled at build-time by modifying kernel/sched/features.h. There is no userspace ABI involved. > >> >> Exposing this option as an ABI in this way exposes too much internal >> ring buffer implementation details to userspace. > > There's already lots of exposure using options. The options are just > knobs, nothing more. > >> >> It exposes the following details which IMHO should be hidden or >> configurable in a way that allows moving to a whole new mechanism >> which will have significantly different characteristics in the >> future: >> >> It exposes that: >> >> - filtering uses a copy to a temporary buffer, and >> - that this copy is enabled by default. >> >> Once exposed, those design constraints become immutable due to ABI. > > No it is not. There is no such thing as "immutable ABI". The rule is > "don't break user space" If this functionality in the kernel goes away, > the knob could become a nop, and I doubt any user space will break > because of it. > > That is, the only burden is keeping this option exposed. But it could > be just like that light switch that has nothing connected to it. It's > still there, but does nothing if you switch it. This knob can act the > same way. This does not in anyway prevent future innovation. I am not comfortable with exposing internal ring buffer implementation details to userspace which may or may not be deprecated as no-ops in the future. This will lead to useless clutter. One approach that might be somewhat better would be to only expose those files when a new CONFIG_TRACING_DEBUG option is enabled. This way userspace cannot rely on having those files present as part of the ABI, but you would still be free to use them for selftests by skipping the specific selftests if the config option is not enabled. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com