That's a fine and fair principle. I understand where you're coming from, and getting this mainlined is important to me too. But for the record, we're maintaini

That's a fine and fair principle. I understand where you're coming from, and getting this mainlined is important to me too. But for the record, we're maintaining meticulous compatibility with all kernel.org kernels back to 3.10 and up to whatever the most recent RCs are (at the moment, 4.17-rc5). We also support the frankenkernels from ubuntu, redhat, and suse. We have a build and run-in-a-vm CI box testing all these kernels for every commit and on a bunch of architectures: https://www.wireguard.com/build-status/ https://www.wireguard.com/build-status/ And because we're actively working on upstreaming this, you can be sure that this is going to continue working with upstream. Also, this isn't a "company releasing their own modules" situation, providing some kind of throw-it-over-the-fence corporate crap code. I'm a kernel developer with a decent amount of upstream code, and the work I do is nearly always for upstream kernels.