Development discussion of WireGuard
 help / color / mirror / Atom feed
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
Date: Tue, 16 Mar 2021 11:37:59 -0600	[thread overview]
Message-ID: <CAHmME9rFU8dknvVfWmRgbLud2bkQMNvVSBqNUfUiBcnTgV90yA@mail.gmail.com> (raw)
In-Reply-To: <CAH8yC8=3o+xDJH25DCWgMCaWbQpViX5QSAvud-ufZb7jpR03bg@mail.gmail.com>

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

  reply	other threads:[~2021-03-16 17:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-16 16:48 Kyle Evans
2021-03-16 17:13 ` Jeffrey Walton
2021-03-16 17:37   ` Jason A. Donenfeld [this message]
2021-03-16 18:24     ` Nicolai
2021-03-16 17:30 ` Jason A. Donenfeld
2021-03-17 12:53 ` Gordon Bergling
2021-03-17 18:34   ` Jason A. Donenfeld
2021-03-17 19:29     ` Wireguard for FreeBSD without iflib Frank Behrens
2021-03-17 22:17       ` Jason A. Donenfeld
2021-03-19  7:47     ` Removing WireGuard Support From FreeBSD Base Gordon Bergling
2021-03-19 10:43       ` Evilham
2021-03-18 16:52 ` Kyle Evans
2021-03-18 16:57   ` Jason A. Donenfeld
2021-03-18 18:49 John Jacobs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHmME9rFU8dknvVfWmRgbLud2bkQMNvVSBqNUfUiBcnTgV90yA@mail.gmail.com \
    --to=jason@zx2c4.com \
    --cc=freebsd-arch@freebsd.org \
    --cc=freebsd-hackers@freebsd.org \
    --cc=kevans@freebsd.org \
    --cc=noloader@gmail.com \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).