From: James Bottomley <James.Bottomley@HansenPartnership.com>
Subject: [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF
Date: Thu, 16 Jun 2022 12:38:24 -0400 [thread overview]
Message-ID: <bbb46f66bb8518e90030fe97a1225adf178654d1.camel@HansenPartnership.com> (raw)
In-Reply-To: <20220616122634.6e11e58c@gandalf.local.home>
On Thu, 2022-06-16 at 12:26 -0400, Steven Rostedt wrote:
> On Wed, 15 Jun 2022 20:25:41 +0200 (CEST)
> Jiri Kosina <jikos@kernel.org> wrote:
>
> > > I might as well ask the naive question: Should subsystems
> > > document
> > > which hooks they intend to treat as ABI? ;-)
>
> I would like there to be a decree that eBPF is denoted as the same as
> a fancy module. And be treated the same as modules. That is, there is
> NO ABI!
Well, you can wish for a Pony, but there's no guarantee you'll get one
...
>
> A eBPF program that works on one kernel should have no guarantee that
> it will work on another version of the kernel. Because eBPF is
> basically just that, a module. It is compiled into native code that
> runs in kernel space. Exactly like a module, with the caveat that it
> must first go through a verifier.
Based on the encouragement we gave as kernel developers, certain
tracing as a service companies that previously had propritary modules
(Sysdig for instance) are now moving over to using tracing with eBPF.
At the time we thought this was good for the kernel; if we now try to
tell them "actually you can't use the interface because it's completely
unstable" that's going to undermine our whole argument to them for
dumping proprietary modules. So I don't think no eBPF at all is stable
is a tenable position for us.
Equally well, I don't think it's as hard as a userspace ABI meaning it
can never change. I think we can get away with changes that force
tracing and other value added service providers to change their eBPF, I
just don't think we can do it very often without damaging the value of
eBPF over proprietary modules.
> > Unfortunately, this "just select a subset" aproach has been proven
> > not to work with tracepoints (which is exactly why some subsytems
> > systematically refused to add tracepoints in the first place,
> > because they explicitly did want to avoid being constrained by
> > tracepoints having to be stable), which in this particular aspect
> > is a similar problem.
As I said above, I think we have to provide *some* stability, but for a
sophisticated consumer it doesn't have to be the absolute stability
guarantee of an ABI. I think we should debate what kinds of slightly
unstable stability we could provide
James
next prev parent reply other threads:[~2022-06-16 16:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-15 6:55 [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF Jiri Kosina
2022-06-15 8:05 ` Linus Walleij
2022-06-15 8:36 ` Jiri Kosina
2022-06-15 17:04 ` Jan Kara
2022-06-15 17:25 ` Jonathan Corbet
[not found] ` <20220615174601.GX1790663@paulmck-ThinkPad-P17-Gen-1>
2022-06-15 18:25 ` Jiri Kosina
2022-06-16 16:26 ` Steven Rostedt
2022-06-16 16:38 ` James Bottomley [this message]
2022-06-16 16:51 ` Steven Rostedt
2022-06-16 18:25 ` James Bottomley
2022-06-16 19:08 ` Steven Rostedt
2022-06-17 7:53 ` Jiri Kosina
2022-06-17 8:24 ` Linus Walleij
2022-06-17 10:30 ` Jan Kara
2022-06-17 11:04 ` Benjamin Tissoires
[not found] ` <dc6ca88d-d1ef-a1ab-dbef-e9338467271d@redhat.com>
2022-06-17 11:25 ` Benjamin Tissoires
2022-06-17 11:32 ` Hans de Goede
2022-06-20 13:13 ` Steven Rostedt
2022-06-21 15:05 ` Steven Rostedt
2022-06-21 16:33 ` Benjamin Tissoires
2022-06-23 20:15 ` Jiri Kosina
2022-06-23 21:23 ` Alexei Starovoitov
2022-06-23 21:36 ` Steven Rostedt
[not found] ` <20220615174358.GA26358@lst.de>
[not found] ` <CAO-hwJKqA07KX+6QtotCS8PtHFtk3DLQPJ3W8puaHOv7tOdi+Q@mail.gmail.com>
[not found] ` <20220616114856.GA11127@lst.de>
2022-06-16 12:14 ` Benjamin Tissoires
[not found] ` <CAO-hwJJmW_STS=nT22n4pcaZf9gz953K4o2vhgmq-ig4OzxOLg@mail.gmail.com>
2022-06-16 8:02 ` Jiri Kosina
2022-06-16 11:37 ` Linus Walleij
2022-06-16 12:09 ` Benjamin Tissoires
2022-06-15 18:35 ` Luis Chamberlain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bbb46f66bb8518e90030fe97a1225adf178654d1.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).