Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <404b3a391bd73acfc29f65d14b1586905ee5103c.camel@perches.com>
Subject: Re: Re: [PATCH v4 0/2] Recommend denylist/allowlist instead of
 blacklist/whitelist
From:   Joe Perches <joe@perches.com>
To:     SeongJae Park <sjpark@amazon.com>, Pavel Machek <pavel@ucw.cz>
Cc:     Jiri Slaby <jslaby@suse.cz>, Michael Ellerman <mpe@ellerman.id.au>,
        akpm@linux-foundation.org, apw@canonical.com,
        SeongJae Park <sjpark@amazon.de>, colin.king@canonical.com,
        sj38.park@gmail.com, linux-kernel@vger.kernel.org
Date:   Mon, 15 Jun 2020 00:00:56 -0700
In-Reply-To: <20200615064631.18910-1-sjpark@amazon.com>
References: <20200615064631.18910-1-sjpark@amazon.com>
Content-Type: text/plain; charset="ISO-8859-1"
User-Agent: Evolution 3.36.2-0ubuntu1 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, 2020-06-15 at 08:46 +0200, SeongJae Park wrote:
> So, I agree this patch is imperfect for many cases, but better than nothing.

Not necessarily.

Having people strain for unusual equivalents
to generally well known terms is not good.

blacklist/whitelist is well understood.

Would you do the same for red/black?