Hello!
This series fix some codingstyle errors in the files
rmgr_vbuf.c, ia_css_rmgr.h, timer.c, spctrl.c and queue.c
in the drivers/staging/media area.
V2:
[Patch 1/12] Also remove NULL, 0 and false members to make it
C99 standard comform.
[Patch 6/12] Checkpatch throws
Hello!
This series fix some codingstyle errors in the files
rmgr_vbuf.c, ia_css_rmgr.h, timer.c, spctrl.c and queue.c
in the drivers/staging/media area.
Best regards
Philipp
--
media: atomsip: Convert comments to C99
Hi Linus,
Am Samstag, 12. September 2020, 13:27:44 CEST schrieb Linus Walleij:
> Jianqun, Heiko,
>
> On Fri, Jan 17, 2020 at 9:14 AM Jianqun Xu wrote:
>
> > Do codingstyle for pinctrl-rockchip by spliting driver by SoC types.
> >
> > Convenienty for reviewin
Jianqun, Heiko,
On Fri, Jan 17, 2020 at 9:14 AM Jianqun Xu wrote:
> Do codingstyle for pinctrl-rockchip by spliting driver by SoC types.
>
> Convenienty for reviewing, the first patch only moving
> pinctrl-rockchip.c from driver/pinctrl to driver/pinctrl/rockchip/ .
>
Hi Dan, and everybody,
Thank you for the patch.
On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
> Recent events have prompted a Linux position statement on inclusive
> terminology. Given that Linux maintains a coding-style and its own
> idiomatic set of terminology here is a
On Mon, Jul 13, 2020 at 1:02 AM Takashi Iwai wrote:
>
> On Wed, 08 Jul 2020 20:14:27 +0200,
> Dan Williams wrote:
> >
> > +Recommended replacements for 'blacklist/whitelist' are:
> > +'denylist / allowlist'
> > +'blocklist / passlist'
>
> I started looking through the tree now and noticed
On Wed 2020-07-08 11:14:27, Dan Williams wrote:
> Linux maintains a coding-style and its own idiomatic set of terminology.
> Update the style guidelines to recommend replacements for the terms
> master/slave and blacklist/whitelist.
>
> Link:
>
Hi!
> +On the triviality of replacing words
> +
> +
> +The African slave trade was a brutal system of human misery deployed at
> +global scale. Some word choice decisions in a modern software project
> +does next to nothing to compensate for that legacy. So why
Add MR_SAME/MR_GRF/MR_PMU definitions, and update data in mux route
structures.
This patch do nothing change, only do some codingstyle.
Signed-off-by: Jianqun Xu
---
drivers/pinctrl/pinctrl-rockchip.c | 674 +
1 file changed, 104 insertions(+), 570 deletions
Add RK3228 definitions to separate from other SoCs.
Signed-off-by: Jianqun Xu
---
drivers/pinctrl/pinctrl-rockchip.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-rockchip.c
b/drivers/pinctrl/pinctrl-rockchip.c
index
Add MR_SAME/MR_GRF/MR_PMU definitions, and update data in mux route
structures.
This patch do nothing change, only do some codingstyle.
Signed-off-by: Jianqun Xu
---
drivers/pinctrl/pinctrl-rockchip.c | 674 +
1 file changed, 104 insertions(+), 570 deletions
Add RK3128 definitions to separate from other SoCs.
Signed-off-by: Jianqun Xu
---
drivers/pinctrl/pinctrl-rockchip.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-rockchip.c
b/drivers/pinctrl/pinctrl-rockchip.c
index
Add RK3368 definitions to separate from other SoCs.
Signed-off-by: Jianqun Xu
---
drivers/pinctrl/pinctrl-rockchip.c | 34 ++
1 file changed, 20 insertions(+), 14 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-rockchip.c
b/drivers/pinctrl/pinctrl-rockchip.c
Add RK3308 definitions to separate from other SoCs.
Signed-off-by: Jianqun Xu
---
drivers/pinctrl/pinctrl-rockchip.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-rockchip.c
b/drivers/pinctrl/pinctrl-rockchip.c
index
Add RK3288 definitons to separate from other SoCs.
Signed-off-by: Jianqun Xu
---
drivers/pinctrl/pinctrl-rockchip.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-rockchip.c
b/drivers/pinctrl/pinctrl-rockchip.c
index
Add RK3399 definitions to separate from other SoCs.
Signed-off-by: Jianqun Xu
---
drivers/pinctrl/pinctrl-rockchip.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-rockchip.c
b/drivers/pinctrl/pinctrl-rockchip.c
index
Add RK3399 definitions to separate from other SoCs.
Signed-off-by: Jianqun Xu
---
drivers/pinctrl/pinctrl-rockchip.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-rockchip.c
b/drivers/pinctrl/pinctrl-rockchip.c
index
On Wed, 08 Jul 2020, Dan Williams wrote:
> Linux maintains a coding-style and its own idiomatic set of terminology.
> Update the style guidelines to recommend replacements for the terms
> master/slave and blacklist/whitelist.
>
> Link:
>
On Tue, 14 Jul 2020 06:39:49 +0200,
j...@joshtriplett.org wrote:
>
> On Mon, Jul 13, 2020 at 10:02:24AM +0200, Takashi Iwai wrote:
> > On Wed, 08 Jul 2020 20:14:27 +0200,
> > Dan Williams wrote:
> > >
> > > +Recommended replacements for 'blacklist/whitelist' are:
> > > +'denylist /
On Mon, Jul 13, 2020 at 10:02:24AM +0200, Takashi Iwai wrote:
> On Wed, 08 Jul 2020 20:14:27 +0200,
> Dan Williams wrote:
> >
> > +Recommended replacements for 'blacklist/whitelist' are:
> > +'denylist / allowlist'
> > +'blocklist / passlist'
>
> I started looking through the tree now
On Sun, Jul 12, 2020 at 9:26 PM Vinod Koul wrote:
>
> Hi Mauro,
>
> On 09-07-20, 13:11, Mauro Carvalho Chehab wrote:
> > Em Mon, 06 Jul 2020 06:30:01 -0700
> > Joe Perches escreveu:
> > >
> > > $ git grep -i -w -P '\w*slave\w*' drivers | \
> > > cut -f1,2 -d/ | uniq -c | sort -rn | head -20 |
On Mon, 2020-07-13 at 10:02 +0200, Takashi Iwai wrote:
> On Wed, 08 Jul 2020 20:14:27 +0200,
> Dan Williams wrote:
> >
> > +Recommended replacements for 'blacklist/whitelist' are:
> > +'denylist / allowlist'
> > +'blocklist / passlist'
>
> I started looking through the tree now and
On Mon, 13 Jul 2020 11:39:56 +0200,
Julia Lawall wrote:
>
>
>
> On Mon, 13 Jul 2020, Takashi Iwai wrote:
>
> > On Mon, 13 Jul 2020 10:43:28 +0200,
> > Julia Lawall wrote:
> > >
> > >
> > >
> > > On Mon, 13 Jul 2020, Takashi Iwai wrote:
> > >
> > > > On Wed, 08 Jul 2020 20:14:27 +0200,
> > > >
On Mon, 13 Jul 2020, Takashi Iwai wrote:
> On Mon, 13 Jul 2020 10:43:28 +0200,
> Julia Lawall wrote:
> >
> >
> >
> > On Mon, 13 Jul 2020, Takashi Iwai wrote:
> >
> > > On Wed, 08 Jul 2020 20:14:27 +0200,
> > > Dan Williams wrote:
> > > >
> > > > +Recommended replacements for
On Mon, 13 Jul 2020 10:43:28 +0200,
Julia Lawall wrote:
>
>
>
> On Mon, 13 Jul 2020, Takashi Iwai wrote:
>
> > On Wed, 08 Jul 2020 20:14:27 +0200,
> > Dan Williams wrote:
> > >
> > > +Recommended replacements for 'blacklist/whitelist' are:
> > > +'denylist / allowlist'
> > > +
On Mon, 13 Jul 2020, Takashi Iwai wrote:
> On Wed, 08 Jul 2020 20:14:27 +0200,
> Dan Williams wrote:
> >
> > +Recommended replacements for 'blacklist/whitelist' are:
> > +'denylist / allowlist'
> > +'blocklist / passlist'
>
> I started looking through the tree now and noticed there are
On Wed, 08 Jul 2020 20:14:27 +0200,
Dan Williams wrote:
>
> +Recommended replacements for 'blacklist/whitelist' are:
> +'denylist / allowlist'
> +'blocklist / passlist'
I started looking through the tree now and noticed there are lots of
patterns like "whitelisted" or "blacklisted". How
On Wed, Jul 08, 2020 at 11:14:27AM -0700, Dan Williams wrote:
> Linux maintains a coding-style and its own idiomatic set of terminology.
> Update the style guidelines to recommend replacements for the terms
> master/slave and blacklist/whitelist.
Acked-by: Joerg Roedel
Hi Mauro,
On 09-07-20, 13:11, Mauro Carvalho Chehab wrote:
> Em Mon, 06 Jul 2020 06:30:01 -0700
> Joe Perches escreveu:
> >
> > $ git grep -i -w -P '\w*slave\w*' drivers | \
> > cut -f1,2 -d/ | uniq -c | sort -rn | head -20 | cat -n
> > 1 5683 drivers/net
> > 2 2118
Hi Dan,
On 08-07-20, 11:14, Dan Williams wrote:
> Linux maintains a coding-style and its own idiomatic set of terminology.
> Update the style guidelines to recommend replacements for the terms
> master/slave and blacklist/whitelist.
>
> Link:
>
On Wed, Jul 08, 2020 at 11:14:27AM -0700, Dan Williams wrote:
> Linux maintains a coding-style and its own idiomatic set of terminology.
> Update the style guidelines to recommend replacements for the terms
> master/slave and blacklist/whitelist.
>
> Link:
>
On Wed 2020-07-08 00:23:59, Dan Williams wrote:
> Linux maintains a coding-style and its own idiomatic set of terminology.
> Update the style guidelines to recommend replacements for the terms
> master/slave and blacklist/whitelist.
>
> +replacements for 'blacklist/whitelist' are:
The pull request you sent on Fri, 10 Jul 2020 17:17:15 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux
> tags/inclusive-terminology
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/49decddd39e5f6132ccd7d9fdc3d7c470b0061bb
Thank you!
--
changes up to a5f526ecb075a08c4a082355020166c7fe13ae27:
CodingStyle: Inclusive Terminology (2020-07-03 23:54:35 -0700)
Extend coding-style with inclusive-terminology recommendations
On 7/8/20 13:14, Dan Williams wrote:
> Linux maintains a coding-style and its own idiomatic set of terminology.
> Update the style guidelines to recommend replacements for the terms
> master/slave and blacklist/whitelist.
>
> Link:
>
On Fri, Jul 10, 2020 at 2:13 PM Laura Abbott wrote:
>
> On 7/8/20 2:14 PM, Dan Williams wrote:
> > Linux maintains a coding-style and its own idiomatic set of terminology.
> > Update the style guidelines to recommend replacements for the terms
> > master/slave and blacklist/whitelist.
> >
[..]
>
On Fri, Jul 10, 2020 at 2:12 PM Andy Lutomirski wrote:
>
> On Wed, Jul 8, 2020 at 11:30 AM Dan Williams wrote:
> >
> > Linux maintains a coding-style and its own idiomatic set of terminology.
> > Update the style guidelines to recommend replacements for the terms
> > master/slave and
On 7/8/20 2:14 PM, Dan Williams wrote:
Linux maintains a coding-style and its own idiomatic set of terminology.
Update the style guidelines to recommend replacements for the terms
master/slave and blacklist/whitelist.
Link:
On Wed, Jul 8, 2020 at 11:30 AM Dan Williams wrote:
>
> Linux maintains a coding-style and its own idiomatic set of terminology.
> Update the style guidelines to recommend replacements for the terms
> master/slave and blacklist/whitelist.
Acked-by: Andy Lutomirski
On Mon, Jul 6, 2020 at 9:30 PM Dan Williams wrote:
>
> On Sat, Jul 4, 2020 at 5:41 PM Kees Cook wrote:
> >
> > On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
> > > Recent events have prompted a Linux position statement on inclusive
> > > terminology. Given that Linux maintains a
On Fri, Jul 10, 2020 at 9:03 AM Linus Walleij wrote:
>
> On Wed, Jul 8, 2020 at 9:40 AM Dan Williams wrote:
>
> > Linux maintains a coding-style and its own idiomatic set of terminology.
> > Update the style guidelines to recommend replacements for the terms
> > master/slave and
On Wed, Jul 8, 2020 at 9:40 AM Dan Williams wrote:
> Linux maintains a coding-style and its own idiomatic set of terminology.
> Update the style guidelines to recommend replacements for the terms
> master/slave and blacklist/whitelist.
>
> Link:
>
>>> Nobody has a problem understanding "blacklist" and "whitelist". These
>>> are universally understood words even outside of computing. Claiming
>>> that we need clearer alternatives is smoke and mirrors.
>>
>> Actually, as a non-native English speaker, the first time I saw
>> "list", I had to
On Thu, Jul 9, 2020 at 2:45 AM Matthias Brugger wrote:
>
>
>
> On 08/07/2020 20:14, Dan Williams wrote:
> > Linux maintains a coding-style and its own idiomatic set of terminology.
> > Update the style guidelines to recommend replacements for the terms
> > master/slave and blacklist/whitelist.
>
On Thu, Jul 9, 2020 at 12:26 AM Daniel Vetter wrote:
>
> On Wed, Jul 8, 2020 at 8:30 PM Dan Williams wrote:
> >
> > Linux maintains a coding-style and its own idiomatic set of terminology.
> > Update the style guidelines to recommend replacements for the terms
> > master/slave and
On Thu, 9 Jul 2020 17:13:51 +0100
Mark Brown wrote:
> On Thu, Jul 09, 2020 at 10:01:18AM -0600, Shuah Khan wrote:
> > On 7/9/20 4:43 AM, Mauro Carvalho Chehab wrote:
>
> > > For coherency, if "blacklist/whitelist" won't be used anymore, an
> > > alternative to graylist should also be
On Thu, 2020-07-09 at 17:13 +0100, Mark Brown wrote:
> On Thu, Jul 09, 2020 at 10:01:18AM -0600, Shuah Khan wrote:
> > On 7/9/20 4:43 AM, Mauro Carvalho Chehab wrote:
> > > For coherency, if "blacklist/whitelist" won't be used anymore, an
> > > alternative to graylist should also be provided.
> >
On Thu, Jul 09, 2020 at 10:01:18AM -0600, Shuah Khan wrote:
> On 7/9/20 4:43 AM, Mauro Carvalho Chehab wrote:
> > For coherency, if "blacklist/whitelist" won't be used anymore, an
> > alternative to graylist should also be provided.
> What is "graylist"? Does it mean in between allow/deny?
Yes.
On 7/9/20 4:43 AM, Mauro Carvalho Chehab wrote:
Em Tue, 7 Jul 2020 01:58:21 +0200
Tibor Raschko escreveu:
Allowlist/denylist terms are intuitive and action based which have a
globally uniform meaning.
Nobody has a problem understanding "blacklist" and "whitelist". These
are universally
Em Mon, 06 Jul 2020 06:30:01 -0700
Joe Perches escreveu:
> On Mon, 2020-07-06 at 09:04 -0400, Matthew Wilcox wrote:
> > On Mon, Jul 6, 2020 at 8:59 AM Joe Perches wrote:
> > > On Mon, 2020-07-06 at 08:51 -0400, Matthew Wilcox wrote:
> > > > In terms of number of lines of code using the
Em Tue, 7 Jul 2020 01:58:21 +0200
Tibor Raschko escreveu:
> > Allowlist/denylist terms are intuitive and action based which have a
> > globally uniform meaning.
>
> Nobody has a problem understanding "blacklist" and "whitelist". These
> are universally understood words even outside of
On 08/07/2020 20:14, Dan Williams wrote:
Linux maintains a coding-style and its own idiomatic set of terminology.
Update the style guidelines to recommend replacements for the terms
master/slave and blacklist/whitelist.
Link:
On Wed, Jul 8, 2020 at 8:30 PM Dan Williams wrote:
>
> Linux maintains a coding-style and its own idiomatic set of terminology.
> Update the style guidelines to recommend replacements for the terms
> master/slave and blacklist/whitelist.
>
> Link:
>
On Wed, 08 Jul 2020 00:23:59 -0700
Dan Williams wrote:
> Linux maintains a coding-style and its own idiomatic set of terminology.
> Update the style guidelines to recommend replacements for the terms
> master/slave and blacklist/whitelist.
>
> Link:
>
On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
> Recent events have prompted a Linux position statement on inclusive
> terminology. Given that Linux maintains a coding-style and its own
> idiomatic set of terminology here is a proposal to answer the call to
> replace non-inclusive
Linux maintains a coding-style and its own idiomatic set of terminology.
Update the style guidelines to recommend replacements for the terms
master/slave and blacklist/whitelist.
Link:
http://lore.kernel.org/r/159389297140.2210796.13590142254668787525.st...@dwillia2-desk3.amr.corp.intel.com
On 7/8/20 1:23 AM, Dan Williams wrote:
Linux maintains a coding-style and its own idiomatic set of terminology.
Update the style guidelines to recommend replacements for the terms
master/slave and blacklist/whitelist.
Link:
On Wed, Jul 08, 2020 at 12:23:59AM -0700, Dan Williams wrote:
> Linux maintains a coding-style and its own idiomatic set of terminology.
> Update the style guidelines to recommend replacements for the terms
> master/slave and blacklist/whitelist.
>
> Link:
>
On Wed, 2020-07-08 at 04:04 -0700, Joe Perches wrote:
> On Wed, 2020-07-08 at 00:23 -0700, Dan Williams wrote:
> > Linux maintains a coding-style and its own idiomatic set of
> > terminology.
> > Update the style guidelines to recommend replacements for the terms
> > master/slave and
On Wed, Jul 8, 2020 at 4:05 AM Joe Perches wrote:
>
> On Wed, 2020-07-08 at 00:23 -0700, Dan Williams wrote:
> > Linux maintains a coding-style and its own idiomatic set of terminology.
> > Update the style guidelines to recommend replacements for the terms
> > master/slave and
On Wed, Jul 8, 2020 at 1:22 AM Kees Cook wrote:
>
> On Wed, Jul 08, 2020 at 12:23:59AM -0700, Dan Williams wrote:
> > Linux maintains a coding-style and its own idiomatic set of terminology.
> > Update the style guidelines to recommend replacements for the terms
> > master/slave and
On Wed, Jul 08, 2020 at 12:23:59AM -0700, Dan Williams wrote:
> Linux maintains a coding-style and its own idiomatic set of terminology.
> Update the style guidelines to recommend replacements for the terms
> master/slave and blacklist/whitelist.
>
> Link:
>
On Wed, 2020-07-08 at 00:23 -0700, Dan Williams wrote:
> Linux maintains a coding-style and its own idiomatic set of terminology.
> Update the style guidelines to recommend replacements for the terms
> master/slave and blacklist/whitelist.
>
> Link:
>
On 08/07/2020 06:42, Stephen Hemminger wrote:
> On Tue, 7 Jul 2020 02:03:36 +0300
> Pavel Begunkov wrote:
>
>> On 07/07/2020 01:28, Steven Rostedt wrote:
>>> On Tue, 7 Jul 2020 01:17:47 +0300
>>> Pavel Begunkov wrote:
>>>
Totally agree with you! But do we care then whether two _devices_
Signed-off-by: Dan Carpenter
regards,
dan carpenter
On Wed, Jul 08, 2020 at 12:23:59AM -0700, Dan Williams wrote:
> Linux maintains a coding-style and its own idiomatic set of terminology.
> Update the style guidelines to recommend replacements for the terms
> master/slave and blacklist/whitelist.
Reviwed-by: Mark Brown
> +'host/{device,proxy}',
On Wed, 8 Jul 2020 00:12:03 -0700 Dan Williams wrote:
> On Mon, Jul 6, 2020 at 11:56 PM SeongJae Park wrote:
> >
> > Hello,
> >
> > On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams
> > wrote:
> >
> > > Recent events have prompted a Linux position statement on inclusive
> > > terminology. Given
On Wed, Jul 08, 2020 at 12:23:59AM -0700, Dan Williams wrote:
> Linux maintains a coding-style and its own idiomatic set of terminology.
> Update the style guidelines to recommend replacements for the terms
> master/slave and blacklist/whitelist.
>
> Link:
>
On Wed, Jul 8, 2020 at 12:40 AM Dan Williams wrote:
>
> Linux maintains a coding-style and its own idiomatic set of terminology.
> Update the style guidelines to recommend replacements for the terms
> master/slave and blacklist/whitelist.
>
> Link:
>
Linux maintains a coding-style and its own idiomatic set of terminology.
Update the style guidelines to recommend replacements for the terms
master/slave and blacklist/whitelist.
Link:
http://lore.kernel.org/r/159389297140.2210796.13590142254668787525.st...@dwillia2-desk3.amr.corp.intel.com
Cc:
On Mon, Jul 6, 2020 at 11:56 PM SeongJae Park wrote:
>
> Hello,
>
> On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams
> wrote:
>
> > Recent events have prompted a Linux position statement on inclusive
> > terminology. Given that Linux maintains a coding-style and its own
> > idiomatic set of
On Tue, 7 Jul 2020 02:03:36 +0300
Pavel Begunkov wrote:
> On 07/07/2020 01:28, Steven Rostedt wrote:
> > On Tue, 7 Jul 2020 01:17:47 +0300
> > Pavel Begunkov wrote:
> >
> >> Totally agree with you! But do we care then whether two _devices_ or
> >> _objects_
> >> are slave-master? Can't see
> Blacklist most definitely has a negative connotation in technical use.
> You blacklist devices that don't work properly, you blacklist drivers
> that don't work for your hardware, you blacklist domains that are
> sending spam or trying to mount network attacks on your servers. Things
> on the
On Tue, Jul 07, 2020 at 01:54:23AM -0700, Kees Cook wrote:
> On Tue, Jul 07, 2020 at 06:56:53AM +, Harrosh, Boaz wrote:
> > Kees Cook wrote:
> > > I have struggled with this as well. The parts of speech change, and my
> > > grammar senses go weird. whitelist = adjective noun. allow-list = verb
On Tue, Jul 07, 2020 at 02:48:25AM +0200, Tibor Raschko wrote:
> > More generally etymological arguments are just not super relevant here
> > anyway, the issues people have are around current perceptions rather
> > than where things came from.
>
> This is where ignoring etymology in this case
On Tue, Jul 07, 2020 at 05:45:42PM +0300, Mike Rapoport wrote:
> On Tue, Jul 07, 2020 at 09:41:47AM -0400, Steven Rostedt wrote:
> > On Tue, 7 Jul 2020 01:54:23 -0700
> > Kees Cook wrote:
> >
> > > "I will whitelist the syscall" -- sounds correct to me (same for
> > > "it is whitelisted" or "it
> -Original Message-
> From: Steven Rostedt
>
> On Tue, 7 Jul 2020 09:49:21 +0300
> Mike Rapoport wrote:
>
> > > But that's all fine. The change is easy to do and is more descriptive
> > > even if I can't find terms that don't collide with my internal grammar
> > > checker. ;)
> >
>
> -Original Message-
> From: Steven Rostedt
>
> On Tue, 7 Jul 2020 08:33:33 -0700
> Randy Dunlap wrote:
>
> > >> I was thinking good-list / bad-list.
> > >>
> > >> /me that has been doing a lot of git bisect lately...
> > >
> > > I think it depends on the context. I'd prefer a
On Tue, 7 Jul 2020 08:33:33 -0700
Randy Dunlap wrote:
> >> I was thinking good-list / bad-list.
> >>
> >> /me that has been doing a lot of git bisect lately...
> >
> > I think it depends on the context. I'd prefer a grammatically awkward verb
> > that described
> > the action more
On 7/7/20 8:24 AM, Bird, Tim wrote:
>
>
>> -Original Message-
>> From: Steven Rostedt
>>
>> On Tue, 7 Jul 2020 09:49:21 +0300
>> Mike Rapoport wrote:
>>
But that's all fine. The change is easy to do and is more descriptive
even if I can't find terms that don't collide with my
On Tue, Jul 07, 2020 at 09:41:47AM -0400, Steven Rostedt wrote:
> On Tue, 7 Jul 2020 01:54:23 -0700
> Kees Cook wrote:
>
> > "I will whitelist the syscall" -- sounds correct to me (same for
> > "it is whitelisted" or "it is in whitelisting mode").
> >
> > "I will allow-list the syscall" --
On Tue, 7 Jul 2020 01:54:23 -0700
Kees Cook wrote:
> "I will whitelist the syscall" -- sounds correct to me (same for
> "it is whitelisted" or "it is in whitelisting mode").
>
> "I will allow-list the syscall" -- sounds wrong to me (same for
> "it is allow-listed" or "it is in allow-listing
On Tue, 7 Jul 2020 09:49:21 +0300
Mike Rapoport wrote:
> > But that's all fine. The change is easy to do and is more descriptive
> > even if I can't find terms that don't collide with my internal grammar
> > checker. ;)
>
> How about yeslist and nolist? ;-)
I was thinking good-list /
On Tue, Jul 07, 2020 at 06:56:53AM +, Harrosh, Boaz wrote:
> Kees Cook wrote:
> > I have struggled with this as well. The parts of speech change, and my
> > grammar senses go weird. whitelist = adjective noun. allow-list = verb
> > noun. verbing the adj/noun combo feels okay, but verbing a
On Mon, Jul 06, 2020 at 09:08:57PM -0700, Dan Williams wrote:
> On Mon, Jul 6, 2020 at 12:16 PM Mark Brown wrote:
> > This, especially the bit about "revelation of 2020", sounds a little
> > off to me - I think it's that it's worryingly close to the frequently
> > derided pattern where people
On Tue, Jul 07, 2020 at 06:56:53AM +, Harrosh, Boaz wrote:
> Kees Cook wrote:
> > I have struggled with this as well. The parts of speech change, and my
> > grammar senses go weird. whitelist = adjective noun. allow-list = verb
> > noun. verbing the adj/noun combo feels okay, but verbing a
On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
> Recent events have prompted a Linux position statement on inclusive
> terminology. Given that Linux maintains a coding-style and its own
> idiomatic set of terminology here is a proposal to answer the call to
> replace non-inclusive
Kees Cook wrote:
> I have struggled with this as well. The parts of speech change, and my
> grammar senses go weird. whitelist = adjective noun. allow-list = verb
> noun. verbing the adj/noun combo feels okay, but verbing a verb/noun is
> weird.
> And just using "allowed" and "denied" doesn't
Hello,
On Sat, 04 Jul 2020 13:02:51 -0700 Dan Williams
wrote:
> Recent events have prompted a Linux position statement on inclusive
> terminology. Given that Linux maintains a coding-style and its own
> idiomatic set of terminology here is a proposal to answer the call to
> replace
On Mon, Jul 06, 2020 at 10:56:17PM -0700, Kees Cook wrote:
> On Mon, Jul 06, 2020 at 09:29:46AM -0700, Andy Lutomirski wrote:
> > Is most contexts where 'whitelist' or 'blacklist' might be used, a
> > descriptive phrase could be used instead. For example, a seccomp
> > filter could have a 'list
On Mon, Jul 06, 2020 at 09:29:46AM -0700, Andy Lutomirski wrote:
> Is most contexts where 'whitelist' or 'blacklist' might be used, a
> descriptive phrase could be used instead. For example, a seccomp
> filter could have a 'list of allowed syscalls' or a 'list of
> disallowed syscalls', and just
On Sat, Jul 4, 2020 at 5:41 PM Kees Cook wrote:
>
> On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
> > Recent events have prompted a Linux position statement on inclusive
> > terminology. Given that Linux maintains a coding-style and its own
> > idiomatic set of terminology here is
On Mon, Jul 6, 2020 at 9:07 AM Mike Rapoport wrote:
>
> Hi Chris,
>
> On Mon, Jul 06, 2020 at 12:45:34PM +, Chris Mason via Ksummit-discuss
> wrote:
> > On 5 Jul 2020, at 0:55, Willy Tarreau wrote:
> >
> > > On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
> > >> +Non-inclusive
On Mon, Jul 6, 2020 at 12:16 PM Mark Brown wrote:
>
> On Sat, Jul 04, 2020 at 01:02:51PM -0700, Dan Williams wrote:
>
> > +'blacklist'. Recommended replacements for 'slave' are: 'secondary',
> > +'subordinate', 'replica', 'responder', 'follower', 'proxy', or
>
> I'd second the suggestion of
On Mon, Jul 6, 2020 at 11:30 AM Shuah Khan wrote:
>
> On 7/4/20 2:02 PM, Dan Williams wrote:
> > Recent events have prompted a Linux position statement on inclusive
> > terminology. Given that Linux maintains a coding-style and its own
> > idiomatic set of terminology here is a proposal to answer
On Mon, Jul 6, 2020 at 9:30 AM Andy Lutomirski wrote:
>
> On Sat, Jul 4, 2020 at 1:19 PM Dan Williams wrote:
> >
> > Recent events have prompted a Linux position statement on inclusive
> > terminology. Given that Linux maintains a coding-style and its own
> > idiomatic set of terminology here is
> More generally etymological arguments are just not super relevant here
> anyway, the issues people have are around current perceptions rather
> than where things came from.
This is where ignoring etymology in this case falls apart, claiming that the
current meaning is more important than the
> The suggestions you made will help us adapt inclusive terminology
> for the current times, and also help us move toward terms that are
> intuitive and easier to understand keeping our global developer
> community in mind.
> Allowlist/denylist terms are intuitive and action based which have a
>
On 07/07/2020 01:28, Steven Rostedt wrote:
> On Tue, 7 Jul 2020 01:17:47 +0300
> Pavel Begunkov wrote:
>
>> Totally agree with you! But do we care then whether two _devices_ or
>> _objects_
>> are slave-master? Can't see how it fundamentally differs.
>
> The term slave carries a lot more
On Tue, 7 Jul 2020 01:17:47 +0300
Pavel Begunkov wrote:
> Totally agree with you! But do we care then whether two _devices_ or _objects_
> are slave-master? Can't see how it fundamentally differs.
The term slave carries a lot more meaning than subordinate. I replied to
someone else but later
1 - 100 of 999 matches
Mail list logo
