[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200615064631.18910-1-sjpark@amazon.com>
Date: Mon, 15 Jun 2020 08:46:31 +0200
From: SeongJae Park <sjpark@...zon.com>
To: Pavel Machek <pavel@....cz>
CC: Jiri Slaby <jslaby@...e.cz>, Michael Ellerman <mpe@...erman.id.au>,
SeongJae Park <sjpark@...zon.com>,
Joe Perches <joe@...ches.com>, <akpm@...ux-foundation.org>,
<apw@...onical.com>, SeongJae Park <sjpark@...zon.de>,
<colin.king@...onical.com>, <sj38.park@...il.com>,
<linux-kernel@...r.kernel.org>
Subject: Re: Re: [PATCH v4 0/2] Recommend denylist/allowlist instead of blacklist/whitelist
On Mon, 15 Jun 2020 08:12:08 +0200 Pavel Machek <pavel@....cz> wrote:
>
> [-- Attachment #1: Type: text/plain, Size: 1115 bytes --]
>
> On Mon 2020-06-15 06:21:43, Jiri Slaby wrote:
> > On 14. 06. 20, 23:29, Pavel Machek wrote:
>
> > >> It's not like blacklist / whitelist are even good to begin with, it's
> > >> not obvious which is which, you have to learn that black is bad and
> > >> white is good.
> > >>
> > >> Blocklist (or denylist?) and allowlist are actually more descriptive and
> > >> less likely to cause confusion.
> > >
> > > You do not understand how word "blacklist" is used inside the kernel,
> > > do you? Do a quick grep.
I of course did grep of the terms before making this patchset. There are so
many uses of the term, and therefore I thought it would be very hard and
painful to replace the whole words. Of course, I also found some miuse of the
terms and therefore I thought automatic scripting for the replacement also
wouldn't make sense.
That's why I made gives only warning to future patches. What this patch aims
to do is avoiding the further spread of the terms, and incremental replacements
to better terms, rather than the one point buggy and risky replacement.
> >
> > And now, do the same for "blocklist".
> >
> > And is "denylist" a proper word? As grep gives zarro results...
> >
> > It's not that easy to find alternatives. OTOH, admittedly, "blacklist"
> > is used improperly in some contexts. Some synonyms fit better.
>
> Well, many of the uses is "list of hardware that needs particular
> workaround" or "list of hardware that is broken in some
> way"... Neither 'blocklist' nor 'denylist' fit that usage.
Agreed, 'denylist' would also not fit in there. That said, this patchset will
warn even such case so that people can think once again and find better term.
So, I agree this patch is imperfect for many cases, but better than nothing.
Thanks,
SeongJae Park
Powered by blists - more mailing lists