Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF

From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	 Hans de Goede <hdegoede@redhat.com>,
	ksummit@lists.linux.dev
Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF
Date: Thu, 23 Jun 2022 14:23:51 -0700	[thread overview]
Message-ID: <CAADnVQ+4B3g9AwYp5zXXJ2c-G1L-aK69bqP8mztHGG2QgzwhaQ@mail.gmail.com> (raw)
In-Reply-To: <nycvar.YFH.7.76.2206232215020.14340@cbobk.fhfr.pm>

On Thu, Jun 23, 2022 at 1:15 PM Jiri Kosina <jikos@kernel.org> wrote:
>
> On Tue, 21 Jun 2022, Benjamin Tissoires wrote:
>
> > > I'm currently at the Open Source Summit, and Dirk basically asked my
> > > question almost verbatim to Linus (during the "Dirk and Linus show").
> >
> > Heh, interesting :)
>
> I guess that also sort of underlines the point that this discussion is
> relevant :)
>
> > Hmm, OK, but I am not sure we are all talking about the same thing here.
> >
> > For real user space applications using eBPF, AFAICT, today we have
> > cgroups and network filtering. And for those 2 applications, given that
> > there is a well defined eBPF API, it wouldn't surprise me that
> > maintainers should take care of the user space breakage.
> >
> > However, if I decide to attach a random BPF program to random functions
> > in the kernel without any involvement in the kernel, and use it to get
> > some metrics, how can we consider this to be plain debugging or an
> > actual user space application (assuming I share it with the rest of the
> > world)?
> >
> > So IMO, we can not assume that any user space application relying on
> > eBPF should never break if that application is hooking to random
> > functions in the kernel. If that user space application is using a well
> > defined (not-an-)API, then yes, this is something maintainers should be
> > aware of.
>
> And we have been exactly here with traceevents/tracepoints, as far as I
> can tell.

Apples are similar to oranges in many ways.

> It was introduced mostly for debugging and profiling purposes. Then some
> random Joe Developer wrote his 'ubertrace' tracing tool that had hard
> dependency on format of some of those, and they they changed, this
> publicly available tool broke. I don't see how eBPF makes this in
> principle different, and that's exactly why I brought this up. Because
> every maintainer is potentially involved/affected, even those who have no
> idea whatsoever yet what eBPF is.

tracepoints exposed an api through cat-able and echo-able files
that 'ubertrace' can use without any knowledge of the underlying kernel,
without access to kernel sources, etc.
Now please explain how bpf based tracing tools are similar?
What exposed api do they use?