From: SeongJae Park <[email protected]>
This patchset 1) adds support of deprecated terms in the 'checkpatch.pl'
and 2) set the 'blacklist' and 'whitelist' as deprecated with
replacement suggestion of 'denylist' and 'allowlist', because the
suggestions are incontrovertible, doesn't make people hurt, and more
self-explanatory.
The patches are based on latest 'next/master'. You can get the complete
git tree at:
https://github.com/sjp38/linux/tree/patches/checkpatch/deprecate_blacklist_whitelist_on_next_v4
Patch History
=============
Changes from v3
(https://lore.kernel.org/lkml/[email protected]/)
- Reuse the file read code for 'spelling.txt' (Joe Perches)
- Suggest 'denylist' rather than 'blocklist' (Jiri Slaby)
- Rebased on today's next/master
Changes from v2
(https://lore.kernel.org/lkml/[email protected]/)
- Implement and use deprecated terms check
Changes from v1
(https://lore.kernel.org/lkml/[email protected]/)
- Remove unnecessary commit message
SeongJae Park (2):
checkpatch: support deprecated terms checking
scripts/deprecated_terms: Recommend denylist/allowlist instead of
blacklist/whitelist
scripts/checkpatch.pl | 60 +++++++++++++++++++++++++++---------
scripts/deprecated_terms.txt | 7 +++++
2 files changed, 52 insertions(+), 15 deletions(-)
create mode 100644 scripts/deprecated_terms.txt
--
2.17.1
From: SeongJae Park <[email protected]>
This commit recommends the patches to replace 'blacklist' and
'whitelist' with the 'denylist' and 'allowlist', because the new
suggestions are incontrovertible, doesn't make people hurt, and more
self-explanatory.
Signed-off-by: SeongJae Park <[email protected]>
---
scripts/deprecated_terms.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/scripts/deprecated_terms.txt b/scripts/deprecated_terms.txt
index 6faa06451c3d..4512ef5d5ffa 100644
--- a/scripts/deprecated_terms.txt
+++ b/scripts/deprecated_terms.txt
@@ -3,3 +3,5 @@
# The format of each line is:
# deprecated||suggested
#
+blacklist||denylist
+whitelist||allowlist
--
2.17.1
On Thu, 2020-06-11 at 08:25 +0200, SeongJae Park wrote:
> From: SeongJae Park <[email protected]>
>
> This patchset 1) adds support of deprecated terms in the 'checkpatch.pl'
> and 2) set the 'blacklist' and 'whitelist' as deprecated with
> replacement suggestion of 'denylist' and 'allowlist', because the
> suggestions are incontrovertible, doesn't make people hurt, and more
> self-explanatory.
While the checkpatch implementation is better,
I'm still very "meh" about the whole concept.
On Wed, 10 Jun 2020 23:35:24 -0700 Joe Perches <[email protected]> wrote:
> On Thu, 2020-06-11 at 08:25 +0200, SeongJae Park wrote:
> > From: SeongJae Park <[email protected]>
> >
> > This patchset 1) adds support of deprecated terms in the 'checkpatch.pl'
> > and 2) set the 'blacklist' and 'whitelist' as deprecated with
> > replacement suggestion of 'denylist' and 'allowlist', because the
> > suggestions are incontrovertible, doesn't make people hurt, and more
> > self-explanatory.
>
> While the checkpatch implementation is better,
> I'm still very "meh" about the whole concept.
I can understand your concerns about politic things in the second patch.
However, the concept of the 'deprecated terms' in the first patch is not
political but applicable to the general cases. We already had the commits[1]
for a similar case. So, could you ack for at least the first patch?
[1] https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Hugs
Thanks,
SeongJae Park
On 11. 06. 20, 9:38, SeongJae Park wrote:
> On Wed, 10 Jun 2020 23:35:24 -0700 Joe Perches <[email protected]> wrote:
>
>> On Thu, 2020-06-11 at 08:25 +0200, SeongJae Park wrote:
>>> From: SeongJae Park <[email protected]>
>>>
>>> This patchset 1) adds support of deprecated terms in the 'checkpatch.pl'
>>> and 2) set the 'blacklist' and 'whitelist' as deprecated with
>>> replacement suggestion of 'denylist' and 'allowlist', because the
>>> suggestions are incontrovertible, doesn't make people hurt, and more
>>> self-explanatory.
>>
>> While the checkpatch implementation is better,
>> I'm still very "meh" about the whole concept.
>
> I can understand your concerns about politic things in the second patch.
> However, the concept of the 'deprecated terms' in the first patch is not
> political but applicable to the general cases. We already had the commits[1]
> for a similar case. So, could you ack for at least the first patch?
>
> [1] https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Hugs
Fuck you! replaced by hug you! is a completely different story. The
former is indeed offending to majority (despite it's quite common to
tell someone "fuck you" in my subregion; OTOH hugging, no way -- I'm a
straight non-communist). If it turns out that any word (e.g. blacklist)
offends _majority_ (or at least a significant part of it) of some
minority or culture, then sure, we should send it to /dev/null. But we
should by no means listen to extreme individuals.
thanks,
--
js
suse labs
On Thu, 11 Jun 2020 10:16:09 +0200 Jiri Slaby <[email protected]> wrote:
> On 11. 06. 20, 9:38, SeongJae Park wrote:
> > On Wed, 10 Jun 2020 23:35:24 -0700 Joe Perches <[email protected]> wrote:
> >
> >> On Thu, 2020-06-11 at 08:25 +0200, SeongJae Park wrote:
> >>> From: SeongJae Park <[email protected]>
> >>>
> >>> This patchset 1) adds support of deprecated terms in the 'checkpatch.pl'
> >>> and 2) set the 'blacklist' and 'whitelist' as deprecated with
> >>> replacement suggestion of 'denylist' and 'allowlist', because the
> >>> suggestions are incontrovertible, doesn't make people hurt, and more
> >>> self-explanatory.
> >>
> >> While the checkpatch implementation is better,
> >> I'm still very "meh" about the whole concept.
> >
> > I can understand your concerns about politic things in the second patch.
> > However, the concept of the 'deprecated terms' in the first patch is not
> > political but applicable to the general cases. We already had the commits[1]
> > for a similar case. So, could you ack for at least the first patch?
> >
> > [1] https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Hugs
>
> Fuck you! replaced by hug you! is a completely different story. The
> former is indeed offending to majority (despite it's quite common to
> tell someone "fuck you" in my subregion; OTOH hugging, no way -- I'm a
> straight non-communist). If it turns out that any word (e.g. blacklist)
> offends _majority_ (or at least a significant part of it) of some
> minority or culture, then sure, we should send it to /dev/null. But we
> should by no means listen to extreme individuals.
Thank you for the opinion. But, my point here is, deprecating some terms would
occur in general as the f-word to hug replacement was, and the first patch is a
simple technical preparation for such case. And, therefore, it would not need
to be blocked due to the second patch.
For example, as it seems at least you and I agree on the f-word to hug
replacement, we could add ``fuck||hug`` in the `deprecated_terms.txt` file to
avoid future spread of the f-words.
Also, I personally don't think the second patch as a political extreme change
but just a right thing to do. Nonetheless, I also understand people could
think in different ways. Moreover, it is obviously non-technical thing which I
am really bad at.
For the reason, I am CC-ing the code of conduct committees[1]. I would like to
hear their opinions on this.
[1] https://www.kernel.org/code-of-conduct.html
Thanks,
SeongJae Park
>
> thanks,
> --
> js
> suse labs
On 11. 06. 20, 10:30, SeongJae Park wrote:
> For example, as it seems at least you and I agree on the f-word to hug
> replacement, we could add ``fuck||hug`` in the `deprecated_terms.txt` file to
> avoid future spread of the f-words.
You will likely get my ACK on that, if that helps.
thanks,
--
js
suse labs
On Thu, 2020-06-11 at 10:32 +0200, Jiri Slaby wrote:
> On 11. 06. 20, 10:30, SeongJae Park wrote:
> > For example, as it seems at least you and I agree on the f-word to hug
> > replacement, we could add ``fuck||hug`` in the `deprecated_terms.txt` file to
> > avoid future spread of the f-words.
>
> You will likely get my ACK on that, if that helps.
But likely not mine.
$ git grep -i '\bfuck' | wc -l
15
On Thu, 11 Jun 2020 03:43:32 -0700 Joe Perches <[email protected]> wrote:
> On Thu, 2020-06-11 at 10:32 +0200, Jiri Slaby wrote:
> > On 11. 06. 20, 10:30, SeongJae Park wrote:
> > > For example, as it seems at least you and I agree on the f-word to hug
> > > replacement, we could add ``fuck||hug`` in the `deprecated_terms.txt` file to
> > > avoid future spread of the f-words.
> >
> > You will likely get my ACK on that, if that helps.
>
> But likely not mine.
It's ok, I will respect every opinion. But...
>
> $ git grep -i '\bfuck' | wc -l
> 15
I'm not understanding what you're meaning with this. Could I ask your
explanation, please?
Thanks,
SeongJae Park
On Fri, 2020-06-12 at 08:40 +0200, SeongJae Park wrote:
> On Thu, 11 Jun 2020 03:43:32 -0700 Joe Perches <[email protected]> wrote:
> > On Thu, 2020-06-11 at 10:32 +0200, Jiri Slaby wrote:
> > > On 11. 06. 20, 10:30, SeongJae Park wrote:
> > > > For example, as it seems at least you and I agree on the f-word to hug
> > > > replacement, we could add ``fuck||hug`` in the `deprecated_terms.txt` file to
> > > > avoid future spread of the f-words.
[]
> > $ git grep -i '\bfuck' | wc -l
> > 15
>
> I'm not understanding what you're meaning with this. Could I ask your
> explanation, please?
Just that there are 15 instances of that word in the kernel.
cheers, Joe
Jiri Slaby <[email protected]> writes:
> On 11. 06. 20, 9:38, SeongJae Park wrote:
>> On Wed, 10 Jun 2020 23:35:24 -0700 Joe Perches <[email protected]> wrote:
>>> On Thu, 2020-06-11 at 08:25 +0200, SeongJae Park wrote:
>>>> From: SeongJae Park <[email protected]>
>>>>
>>>> This patchset 1) adds support of deprecated terms in the 'checkpatch.pl'
>>>> and 2) set the 'blacklist' and 'whitelist' as deprecated with
>>>> replacement suggestion of 'denylist' and 'allowlist', because the
>>>> suggestions are incontrovertible, doesn't make people hurt, and more
>>>> self-explanatory.
>>>
>>> While the checkpatch implementation is better,
>>> I'm still very "meh" about the whole concept.
>>
>> I can understand your concerns about politic things in the second patch.
>> However, the concept of the 'deprecated terms' in the first patch is not
>> political but applicable to the general cases. We already had the commits[1]
>> for a similar case. So, could you ack for at least the first patch?
>>
>> [1] https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Hugs
>
> Fuck you! replaced by hug you! is a completely different story. The
> former is indeed offending to majority (despite it's quite common to
> tell someone "fuck you" in my subregion; OTOH hugging, no way -- I'm a
> straight non-communist). If it turns out that any word (e.g. blacklist)
> offends _majority_ (or at least a significant part of it) of some
> minority or culture, then sure, we should send it to /dev/null.
> should by no means listen to extreme individuals.
I agree you have to draw the line somewhere, there will always be
someone somewhere that's offended by something. But this seems like a
pretty easy case.
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.
cheers
On Sat 2020-06-13 00:40:59, Michael Ellerman wrote:
> Jiri Slaby <[email protected]> writes:
> > On 11. 06. 20, 9:38, SeongJae Park wrote:
> >> On Wed, 10 Jun 2020 23:35:24 -0700 Joe Perches <[email protected]> wrote:
> >>> On Thu, 2020-06-11 at 08:25 +0200, SeongJae Park wrote:
> >>>> From: SeongJae Park <[email protected]>
> >>>>
> >>>> This patchset 1) adds support of deprecated terms in the 'checkpatch.pl'
> >>>> and 2) set the 'blacklist' and 'whitelist' as deprecated with
> >>>> replacement suggestion of 'denylist' and 'allowlist', because the
> >>>> suggestions are incontrovertible, doesn't make people hurt, and more
> >>>> self-explanatory.
> >>>
> >>> While the checkpatch implementation is better,
> >>> I'm still very "meh" about the whole concept.
> >>
> >> I can understand your concerns about politic things in the second patch.
> >> However, the concept of the 'deprecated terms' in the first patch is not
> >> political but applicable to the general cases. We already had the commits[1]
> >> for a similar case. So, could you ack for at least the first patch?
> >>
> >> [1] https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Hugs
> >
> > Fuck you! replaced by hug you! is a completely different story. The
> > former is indeed offending to majority (despite it's quite common to
> > tell someone "fuck you" in my subregion; OTOH hugging, no way -- I'm a
> > straight non-communist). If it turns out that any word (e.g. blacklist)
> > offends _majority_ (or at least a significant part of it) of some
> > minority or culture, then sure, we should send it to /dev/null.
> > should by no means listen to extreme individuals.
>
> I agree you have to draw the line somewhere, there will always be
> someone somewhere that's offended by something. But this seems like a
> pretty easy case.
>
> 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.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 14. 06. 20, 23:29, Pavel Machek wrote:
>> I agree you have to draw the line somewhere, there will always be
>> someone somewhere that's offended by something. But this seems like a
>> pretty easy case.
Yes, hence I left up to the minority and/or the touched culture.
>> 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.
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.
thanks,
--
js
suse labs
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.
>
> 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.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, 15 Jun 2020 08:12:08 +0200 Pavel Machek <[email protected]> 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
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?
On Mon 2020-06-15 00:00:56, Joe Perches wrote:
> 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.
Exactly. Plus consistency is good, and having same structure named
blacklist here and naughtyhardwarelist there does not really help.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html