From owner-freebsd-arch@freebsd.org Tue Mar 16 17:38:14 2021 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 44C145B67C5; Tue, 16 Mar 2021 17:38:14 +0000 (UTC) (envelope-from Jason@zx2c4.com) Received: from mail.zx2c4.com (mail.zx2c4.com [104.131.123.232]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.zx2c4.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F0L9L1NZ3z4sB4; Tue, 16 Mar 2021 17:38:14 +0000 (UTC) (envelope-from Jason@zx2c4.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1615916291; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0oGACFIL8J9SZamsqvs/X4H69lOZwPL2+iMeFK6MhcE=; b=U3OaT/czT4X0h5JSLTEeA5233hCkKp/L81RA06SAksefFKwouujUwmgm49X/j0npJ72idh nF71cIOzgE/24EIk93U7b9/Vu9cOe3mOQT2dYXt9DnxXYdHNxQdfFG6v7Tc3aB1+hSIV/k NlRQICD37KEVksvolRO/p/4ijUwLOx4= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id aa3de340 (TLSv1.3:AEAD-AES256-GCM-SHA384:256:NO); Tue, 16 Mar 2021 17:38:11 +0000 (UTC) Received: by mail-yb1-f176.google.com with SMTP id 133so37700501ybd.5; Tue, 16 Mar 2021 10:38:11 -0700 (PDT) X-Gm-Message-State: AOAM532IDmvqj+eIrL2X3NPwGasnGAxXf0b4+qPjMohZNLEejH/fvd2S 0kV5uPfRvGFP2nBVF1tnHq7UMnIIQ2DB1HFFpaM= X-Google-Smtp-Source: ABdhPJxi6Gau0FW2aWBjmPa2EXeZj1hs6B3t0fqJoDRxJLyS+8ZCrqyEFQdLeEpMKWsTelmANlJarC3SMiZ/7Zs/l1Y= X-Received: by 2002:a25:1442:: with SMTP id 63mr13125ybu.123.1615916290654; Tue, 16 Mar 2021 10:38:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Jason A. Donenfeld" Date: Tue, 16 Mar 2021 11:37:59 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Removing WireGuard Support From FreeBSD Base To: Jeffrey Walton Cc: Kyle Evans , freebsd-arch@freebsd.org, FreeBSD Hackers , WireGuard mailing list Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4F0L9L1NZ3z4sB4 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Mailman-Approved-At: Tue, 16 Mar 2021 20:35:33 +0000 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 17:38:14 -0000 Hi Jeffrey, On Tue, Mar 16, 2021 at 11:16 AM Jeffrey Walton 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