6 ms·

But why? Its still very easy to install. Is it just a matter of not trusting kernel extensions?

craftyguy 8y ago
> But why? Principle. I strongly believe that software which runs in kernel space must adhere to the same standards (for better or worse) as the kernel. For Linux kernel modules, this means being accepted into the upstream kernel, and demonstrating a history of maintaining compatibility with the mainline kernel. I've been burned a lot in the past by companies releasing their own modules, and quickly failing to keep up compatibility with the mainline kernel versions. Not going to make that mistake again.
- zx2c4 8y ago
  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.
  - craftyguy 8y ago
    Sure. But I am still looking forward to seeing it in the kernel tree before trying it out.
vetinari 8y ago
If you are using secure boot and distro-provided kernels, building and signing your own kernel modules is a PITA.
foobarbazetc 8y ago
Out of tree modules are a huge PITA on enterprise deployments. They also taint the kernel...

> But why? Principle. I strongly believe that software which runs in kernel space must adhere to the same standards (for better or worse) as the kernel. For Linux kernel modules, this means being accepted into the upstream kernel, and demonstrating a history of maintaining compatibility with the mainline kernel. I've been burned a lot in the past by companies releasing their own modules, and quickly failing to keep up compatibility with the mainline kernel versions. Not going to make that mistake again.

zx2c4 8y ago
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.
- craftyguy 8y ago
  Sure. But I am still looking forward to seeing it in the kernel tree before trying it out.

vetinari 8y ago

If you are using secure boot and distro-provided kernels, building and signing your own kernel modules is a PITA.

foobarbazetc 8y ago

Out of tree modules are a huge PITA on enterprise deployments. They also taint the kernel...