Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3577858pxb; Wed, 13 Oct 2021 08:43:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyDgoyvYzCcOwPX5p9UNg2BhbziRMHKE6M9T+rzR6PAdITnX19UNiUa1ylHA0VjHOWroBti X-Received: by 2002:a17:906:7113:: with SMTP id x19mr229541ejj.557.1634139825947; Wed, 13 Oct 2021 08:43:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1634139825; cv=none; d=google.com; s=arc-20160816; b=Dm9ytmkvWGp7JiLhh8YExCskx0bVvAQcaMnCSGNrNU6zm71XDHfF6HwC5J9y4B74i4 0QtS7Yu613qd40ljTHnkXEdOrjBCJx23WtXeZqSpIJHheNrTAyNCa8D2xlvuidQjCFIp ei4NxL9e4EjARJbeZLyz/0q9urpVqqMdrGduX3eoCKxyg32hnPLcrdmnsCKY4/ZL32CX pJFHikmjqptOUhaLtb3SqRP8cADvIndq2nwytIFBee9MFEzbTF0VFPZgzs0KPou4KmjO 83PkexDdqN4dsqQxZD+TlFFetiTCm6oXue1MQtSLbEbWrVGLHWBIESiwWlGhaAHwGJAN mN/g== 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=ulTG5gMD+k4RqEZ7e4tmHrCAs56SekXKKyNQsF7uUE4=; b=hKMt9QDt8hGac7sh26Nsmg60/dj7RVWyVJy0gHqqJL5UI/5ros5WABzmSwmtW/ssOM zIsaH5/Tqq3bVI9BoF1yFqMaZta/2tdq68QGqzFhYElhmxf+KHfZp3Mch2Rppz+7Sb6E 4zywfU4Ubqarghl2gt1qQsO1gciZmUiEsi+PUcrc9hSz+zGzNjhkNC+NJo6kVx3N8M5z Cq6GM3FhvYhMKaL5NV7edqTnC9tAOXF3naHTRZhIojeJg89ziNtA7F8lZtsTB7tAAOGy vNJ67DwYyhuazVoU5mbsTRZIA66YlcfrI54jnazz2lQ3kxWeGT+r5J52dFYMEopqQfMF zmNg== 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 hs9si14421840ejc.109.2021.10.13.08.43.21; Wed, 13 Oct 2021 08:43:45 -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 S234141AbhJMPmk (ORCPT + 99 others); Wed, 13 Oct 2021 11:42:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:46524 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229711AbhJMPmk (ORCPT ); Wed, 13 Oct 2021 11:42:40 -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 4E4BE610A0; Wed, 13 Oct 2021 15:40:36 +0000 (UTC) Date: Wed, 13 Oct 2021 11:40:34 -0400 From: Steven Rostedt To: Masami Hiramatsu Cc: Beau Belgrave , linux-trace-devel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] user_events: Enable user processes to create and write to trace events Message-ID: <20211013114034.13daac32@gandalf.local.home> In-Reply-To: <20211014002132.ee7668a4790ea75b0f7a9ceb@kernel.org> References: <20211005224428.2551-1-beaub@linux.microsoft.com> <20211007012827.99cd5795140cbb0c932e1b5a@kernel.org> <20211006175611.GA2995@kbox> <20211007231738.0626e348322dc09e7ebbf1d6@kernel.org> <20211007162204.GA30947@kbox> <20211008081249.8fbacc4f5d9fa7cf2e488d21@kernel.org> <20211008000540.GA31220@kbox> <20211008182258.6bf272e6691679d41e7971fc@kernel.org> <20211011162523.GA1542@kbox> <20211014002132.ee7668a4790ea75b0f7a9ceb@kernel.org> 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-kernel@vger.kernel.org On Thu, 14 Oct 2021 00:21:32 +0900 Masami Hiramatsu wrote: > > This approach requires an FD returned and either an int for the status > > page or the returend FD could expose the ID via another IOCTL being > > issued. > > OK, I would like to suggest you to add events/user-events/*/marker file > (which returns that shared file struct backed FD) so that some simple > user scripts can also send the events (these may not use ioctl, just > write the events.) But this can be done afterwards anyway. > I'd prefer we avoid this. It will break some of the semantics of the events directory. One, only "user-events" will have this "marker" file. Although it will be very similar to the "inject" file, but that's only for debugging anyway. All the files in the events directory is starting to add a bunch of overhead, as they are typically copied into the instances. Although, when we get the eventfs directory created, maybe that will not be as big of a deal. But that still doesn't fix the semantics issue. -- Steve