Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 18 Apr 2022 22:43:29 +0200
From:   Hagen Paul Pfeifer <hagen@jauu.net>
To:     Beau Belgrave <beaub@linux.microsoft.com>
Cc:     rostedt@goodmis.org, mhiramat@kernel.org,
        linux-trace-devel@vger.kernel.org, linux-kernel@vger.kernel.org,
        Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Subject: Re: [PATCH v8 00/12] user_events: Enable user processes to create
 and write to trace events
Message-ID: <Yl3NcRRIJMrd0WZu@laniakea>
References: <20211216173511.10390-1-beaub@linux.microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20211216173511.10390-1-beaub@linux.microsoft.com>
Precedence: bulk

* Beau Belgrave | 2021-12-16 09:34:59 [-0800]:

>The typical scenario is on process start to mmap user_events_status. Processes
>then register the events they plan to use via the REG ioctl. The ioctl reads
>and updates the passed in user_reg struct. The status_index of the struct is
>used to know the byte in the status page to check for that event. The
>write_index of the struct is used to describe that event when writing out to
>the fd that was used for the ioctl call. The data must always include this
>index first when writing out data for an event. Data can be written either by
>write() or by writev().

Hey Beau, a little bit late to the party. A few questions from my side: What
are the exact weak points of USDT compared to User Events that stand in the
way of further extend USDT (in a non-compatible way, sure, just as an
different approach!)? The nice thing about USDT is that I can search for all
possible probes of the system via "find / | readelf | ". Since they are listed
in a dedicated ELF section (.note.stapsdt) - they are visible & transparent. I
can also map a hierarchy/structure in Executable/DSO via clever choice of
names. The big disadvantage of USDT is the lack of type information, but from
a registration, explicit point of view, they are nice.

Or in other words: why not extends the USDT approach? Why not

u32 val = 23;
const char *garbage = "tracestring";

DYNAMIC_TRACE_PROBE2("foo:bar", val, u32, garbage, cstring);


Sure, the argument names, here "val" and "garbage" should also be saved. I
also like the "just one additional header to the project to get things
running" (#include "sdt.h"). Sure, a DYNAMIC_TRACE_IS_ACTIVE("foo:bar") would
be great. But in fact we have never needed that in the past.


hgn