David, On Thu, 17 Oct 2019, David Miller wrote: > From: Thomas Gleixner <tglx@xxxxxxxxxxxxx> > Date: Thu, 17 Oct 2019 23:54:07 +0200 (CEST) > > > Clark might have some insight from the product side for you how much that > > impacts usability. > > You won't even be able to load systemd, it uses bpf. As I said before: At some point in the future from now. Right now I'm writing this mail from a Debian testing system which runs a kernel with Sebastians patch applied. That means a halfways recent systemd started just fine and everything works. You surely made your point. > We're moving to the point where even LSM modules will be implemented in bpf. Emphasis on 'We're moving'. Which means this is in progress and not after the fact. > IR drivers require bpf: > > https://lwn.net/Articles/759188/ The fact that IR drivers require BPF is not a real convincing argument either. Guess how many RT systems depend on functional IR drivers? Guess how many other subsystems are not RT safe and disabled on RT and still RT is successfully deployed in production? Quoting from the other end of that thread just to avoid fragmentation: > > tcpdump and wireshark work perfectly fine on a BPF disabled kernel at least > > in the limited way I am using them. > > Yes it works, but with every packet flowing through the system getting > copied into userspace. This takes us back to 1992 :-) Guess what? RT real world deployments survived for the past 15 years on the packet sniffing state of 1992. There is a world outside of networking... > I understand the problems, and realize they are non-trivial, but this hammer > is really destructive on a fundamental level. The fundamentally desctructive component is that this whole thread does not provide any form of constructive feedback. - Sebastians changelog has a list of the issues - I expanded on those All we got as a reply is a destructive NO along with a long list of half baken arguments why temporary disabling of this functionality solely for RT is unacceptable. It's probably also solely my (our / RT folks) problem that BPF made design decisions which are focussed on (network) performance without considering any other already existing constraints. Sure we have the usual policy that we don't care about out of tree stuff and it's the problem of the out of tree folks to deal with that, but I politely ask you to think hard about this in the context of RT. I'm going to shut up for now and wait for constructive and reasonable feedback how to tackle these issues on a technical level. Thanks, Thomas
