Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp2218693imm; Tue, 2 Oct 2018 23:50:21 -0700 (PDT) X-Google-Smtp-Source: ACcGV63SpkXslAsAp4dxPIGpojKKejjGzO/XdX1scfVBBVL6hb5JT7s3N3TXoREbXv5leuBaGNG5 X-Received: by 2002:a62:3541:: with SMTP id c62-v6mr73704pfa.45.1538549421833; Tue, 02 Oct 2018 23:50:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538549421; cv=none; d=google.com; s=arc-20160816; b=kctuBAakw8XEZAYmK5B2Bzp6o057wZ+1XoJgE7Cc48gk7jfxtbmnloHRPfi/RISiae jmPhReRYKI8UaxzyTv1z9aunAKSoS8+KhBGKnHjTGdLyd//0rh12uE3i4PVmVbnd7cN1 LqZw2wt8SvJZDmBSUklVC/eEyHZm3UJeFvkgAA4drG2TUarxud462UVCwKhT8svzTm/V uvwFQuJkKUf0Z3lcuiNMANU/J4Xm/6HydrLjseLBiiwQwxjCUKwyuDB9UDN7oaF9wgDB nTD6eJgqSk30AoWK/O6UqQeZpm5VZW3ZcnYH9X+OafxJiWhiO3JYOdRoH+6VDUI86mBk vPIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=gWvdyXS66FLJJaHXBDqfyCmIrkNNNsKu08HIyOnI24k=; b=iXcxq0iS7lDhs4AYqr4zseiT8n3W2ODEP5ZZdQyoFVXOUAuzeQX3FH9sUjd9rCuo8q eOq9hGrg3nPbrKs91EVY35tEeDWOcf8+3TKkbosxDl2NTq7XS8ysZuu2QQF/yewtTunA XuyCty2dKsTLEf3U7PeM3dGK+tf3qGrb6T6hGxmS1ebg0Rbo9pH9ZzyXurH90y0sbO7V r+2vv40oHBAwbqdFKB1u7/G4K7okbYTVfYc/WKpUyVr5d9xCUanCly17AlXgnfqrnZrK DS3X9/qxwUUqTqHxnCv+SGGYQFEDX18GXmW+2WyQO65b75tyGHsa0bMhx2GUR4Lrsnz/ KHDg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=oKBz4zcR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 4-v6si613762pfe.142.2018.10.02.23.50.03; Tue, 02 Oct 2018 23:50:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=oKBz4zcR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726739AbeJCNgz (ORCPT + 99 others); Wed, 3 Oct 2018 09:36:55 -0400 Received: from mail.kernel.org ([198.145.29.99]:46262 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726521AbeJCNgz (ORCPT ); Wed, 3 Oct 2018 09:36:55 -0400 Received: from sol.localdomain (c-67-185-97-198.hsd1.wa.comcast.net [67.185.97.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E195420684; Wed, 3 Oct 2018 06:49:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1538549394; bh=9t7ndurSMmuI3q97MNuQ4VgbN4uT7DKgPvKjf9zMjac=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oKBz4zcRTszuKaQUUqC+AUc8k2WOKP9QDw+luNzwwAQQ2BIhkjmzgWIm7SF8lPxcj PrD6pUt47N51sXX6l5tj911IwUjsKBJvinQIvWSutP+9QgKmrzz/+rPXjMxmqy+JJ6 GHp5tbWWQF0YJyu2nneTQaFfhNfJ2cUxxYVOF+O0= Date: Tue, 2 Oct 2018 23:49:52 -0700 From: Eric Biggers To: "Jason A. Donenfeld" Cc: Ard Biesheuvel , Herbert Xu , LKML , Netdev , Linux Crypto Mailing List , David Miller , Greg Kroah-Hartman Subject: Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel Message-ID: <20181003064951.GC745@sol.localdomain> References: <20181002033908.324yhwqaohfsq65d@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 02, 2018 at 02:22:47PM +0200, Jason A. Donenfeld wrote: > On Tue, Oct 2, 2018 at 8:04 AM Ard Biesheuvel wrote: > > Also, I still think the name Zinc (zinc is not crypto/) is needlessly > > divisive and condescending, and unsaying it (in v2 and up) doesn't > > really work on the Internet (especially since you are still repeating > > it in your conference talk.) > > Jason, you seem to hate the existing crypto framework with passion, > > and the name reflects that. > > It's not divisive or condescending. I don't hate the existing > framework with a passion -- this is patently false. The name even with > its original acronym doesn't imply anything essentially negative. I > see that you've repeatedly misinterpreted it this way -- which is why > I removed that from v2 for the avoidance of doubt -- but that doesn't > change the fact that its proper interpretation is not a condescending > or divisive one. > > Look, people love to bikeshed about names. I'm sure you'll be able to > CC-in a large crew of people who have opinions in one way or another, > and this thread could begin to have many voices on that front or on > multiple fronts. There are real benefits of sticking with the name > I've given to the library I've spent enormous amounts of time writing. > And so I'm going to stick with Zinc, since that's why our library is > called. Sorry. We can talk about this at Plumbers in Vancouver if you > want, but I think you're not going to get very far with a mailing list > naming bikeshed. > It's not really about the name, though. It's actually about the whole way of thinking about the submission. Is it a new special library with its own things going on, or is it just some crypto helper functions? It's really just the latter, but you've been presenting it as the former, which is causing a lot of unnecessary confusion and controversy. And I think that largely because you've started from that perspective, you've ended up with some oddities like your own directories in lib/ and include/ separate from the other existing crypto helper functions, and proposals to maintain it completely separately from the existing crypto code including having a separate git tree and separate upstreaming path. For example, we already have include/crypto/. What's the difference between include/crypto/ and include/zinc/? How do users know whether to include e.g. rather than ? And are users going to remember and understand that "zinc" actually means "crypto" but not really? It would be much more straightforward and intuitive if we just had , and your new helper functions were declared in there. Dismissing these concerns as bikeshedding about the name is missing the point. - Eric