LWN: Comments on "User events — but not quite yet"

User events — but not quite yet

anton — Wed, 27 Apr 2022 18:01:50 +0000

It seems to me that the proposed mechanism is expensive when an event is actually monitored: one writev() system call per event. This will limit the uptake even if it gets accepted.

User events — but not quite yet

net_benji — Wed, 20 Apr 2022 08:05:32 +0000

Alexei gave reasons for his disapproval in another thread:
https://lore.kernel.org/linux-trace-devel/CAADnVQJFjXDvqM...

> The whole user_events feature looks redundant to me.
> We have uprobes and usdt. It doesn't look to me that
> user_events provide anything new that wasn't available earlier.

User events — but not quite yet

lathiat — Wed, 20 Apr 2022 06:27:23 +0000

Note that USDT probes can also be defined using headers from systemtap (sys/sdt.h - systemtap-sdt-dev{el,}) but it doesn't actually require systemtap to use it's just where the headers live.

This library generally is GPLv2-only licensed but the relevant sys/sdt.h file is "dedicated to the public domain, pursuant to CC0 (https://creativecommons.org/publicdomain/zero/1.0/)"

It uses the same definitions and is source-compatible with the definitions from DTRACE (so the macros are named DTRACE_*):
https://sourceware.org/systemtap/wiki/AddingUserSpaceProb...
https://sourceware.org/systemtap/wiki/UserSpaceProbeImple...

User events — but not quite yet

geert — Tue, 19 Apr 2022 18:01:26 +0000

The first thing that struck me was the implicit gap between the size and name_args fields. The gap may or may not be present, depending on the alignment rules of an architecture.

User events — but not quite yet

alison — Tue, 19 Apr 2022 04:08:01 +0000

Why is the new mechanism better than uprobes, which have easy-to-use BPF support via the USDT facility in the folly library:

https://github.com/facebook/folly/tree/main/folly/tracing

Compiling against all of folly to get the userspace tracing would be a pain, but the code is Apache-licensed, so perhaps that is not necessary.

User events — but not quite yet

pbonzini — Mon, 18 Apr 2022 22:33:25 +0000

I'm confused, why was this included at all in a pull request? Also Starovoitov's message (https://lwn.net/ml/linux-kernel/CAADnVQK=GCuhTHz=iwv0r7Y3...) completely lacks a description of _why_ the eBPF interface is bad.

All maintainers have a bad day every now and then, but this really looks like a bad example of kernel development.