Date: Tue, 16 Mar 2021 11:37:59 -0600 From: "Jason A. Donenfeld" <Jason@zx2c4.com> To: Jeffrey Walton <noloader@gmail.com> Cc: Kyle Evans <kevans@freebsd.org>, freebsd-arch@freebsd.org, FreeBSD Hackers <freebsd-hackers@freebsd.org>, WireGuard mailing list <wireguard@lists.zx2c4.com> Subject: Re: Removing WireGuard Support From FreeBSD Base Message-ID: <CAHmME9rFU8dknvVfWmRgbLud2bkQMNvVSBqNUfUiBcnTgV90yA@mail.gmail.com> In-Reply-To: <CAH8yC8=3o%2BxDJH25DCWgMCaWbQpViX5QSAvud-ufZb7jpR03bg@mail.gmail.com> References: <CACNAnaHR9Li0wPOjmwRk7jG76-AESoTt0QrrG_UVTrev38N=bQ@mail.gmail.com> <CAH8yC8=3o%2BxDJH25DCWgMCaWbQpViX5QSAvud-ufZb7jpR03bg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Jeffrey, On Tue, Mar 16, 2021 at 11:16 AM Jeffrey Walton <noloader@gmail.com> wrote: > > In the next day or so, I will be committing a removal of all WireGuard > > related bits from our 'main' branch, including the work that I recently > > committed. It will be followed up by a removal of the implementation > > from stable/13, and we will seek appropriate approval to remove it > > from releng/13.0 as well. Please, do not be concerned by any of this; > > this is being done with mutual support from all parties. > > The thing I find unusual is, the move appears to lack technical > justification. The best I can tell, the reasons seem to be political. > But like I said, maybe my feeds are missing something... > > As a naive outsider, if you are going to yank it, then the technical > reasons for the action should be clearly enumerated. Everything else > is just chatter or noise. The move just looks like a bunch of bruised > egos and sour grapes. I'd just like to chime in and point out that although this is happening in a political context as you've pointed out, this is in my opinion the *best possible technical situation*, and the one I would have preferred in the beginning anyway if it were presented as a choice. Here's the technical background you asked for: - We found tons of issues with the original code base. - We spent a week rewriting that codebase. So here's the rationale: - Merging a week-old codebase into an operating system kernel is a bad idea. It's really not more complicated than that. I'm *sure* we'll find more things to fix. That's just the nature of it. And from a practical perspective, it's a lot easier for me, anyway, to casually push fixes as I code to a normal repo on git.zx2c4.com. When there's a lot of potential code churn, sometimes it's easiest to be able to move fast at first. When we get it to a place where we feel extra good about it, then we can do the full review process on what we've got, which has the added benefit of even more eyeballs and ways of looking at things. I think the code will benefit from this type of process. > Maybe a good middle ground would be to take the existing code and put > it in a Wireguard branch. Those who wish to keep Wireguard out of > FreeBSD mainline have done so. FreeBSD users who wish to use Wireguard > can build the Wireguard branch. And those who wish to improve > Wireguard have a working branch for patches. Later, the branch can be > re-merged back to master. We're actually going to do something like that already. We'll have it as an out-of-tree module, since it's fairly standalone anyway. And then when it's ready, we'll send that for merging back into the FreeBSD main branch. Also, from a technical perspective, dealing with out of tree modules on FreeBSD seems way, way easier than on Linux. There's not nearly as much API churn, as far as I can see. We probably can even offer prebuilts at some point for people who want to test out snapshots. So I'm really not very worried (at least at the moment; I'm still new to FreeBSD kernel development). Jason
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHmME9rFU8dknvVfWmRgbLud2bkQMNvVSBqNUfUiBcnTgV90yA>