From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Rostedt Date: Thu, 16 Jun 2022 15:08:45 -0400 Subject: [Ksummit-discuss] [MAINTAINERS SUMMIT] How far to go with eBPF In-Reply-To: References: <20220615170407.ycbkgw5rofidkh7x@quack3.lan> <87h74lvnyf.fsf@meer.lwn.net> <20220615174601.GX1790663@paulmck-ThinkPad-P17-Gen-1> <20220616122634.6e11e58c@gandalf.local.home> <20220616125128.68151432@gandalf.local.home> Message-ID: <20220616150845.22e83f9a@gandalf.local.home> On Thu, 16 Jun 2022 14:25:44 -0400 James Bottomley wrote: > Not if it's managed correctly. One method could simply be to not care > but be careful. After all, lots of companies still manage to produce > proprietary modules even with us actively trying to break the API. > Either it's not as difficult as we think or API changes are easier to > cope with than we assume. All I read from this is that eBPF is the new way that proprietary modules can have their stable API. The problem I have here is that eBPF is becoming extremely invasive. It is now hooking to any function in the kernel that isn't marked notrace. If there's not a clear border on what is considered non-stable now, we will be fighting with those that say "hey this broke my bpf program, revert it please" for a long time coming. -- Steve