On 26.03.21 09:59, Greg KH wrote:
> On Fri, Mar 26, 2021 at 07:13:09AM +0100, Thorsten Leemhuis wrote:
>>
>> Lo! Since a few months mainline in
>> Documentation/admin-guide/reporting-issues.rst contains a text written
>> to obsolete the good old reporting-bugs text. For now, the new document
>> sti
On 26.03.21 07:23, Guenter Roeck wrote:
> On 3/25/21 11:15 PM, Thorsten Leemhuis wrote:
>> On 26.03.21 07:13, Thorsten Leemhuis wrote:
>
>> mention if backporting is planed or considered too complex. If backporting
>> was
> planned
ha, of course, thx for pointing it out! Ciao, Thorsten
On Fri, Mar 26, 2021 at 07:13:09AM +0100, Thorsten Leemhuis wrote:
>
> Lo! Since a few months mainline in
> Documentation/admin-guide/reporting-issues.rst contains a text written
> to obsolete the good old reporting-bugs text. For now, the new document
> still contains a warning at the top that ba
On Fri, Mar 26, 2021 at 07:16:40AM +0100, Thorsten Leemhuis wrote:
> On 26.03.21 07:13, Thorsten Leemhuis wrote:
> > Lo! Since a few months mainline in
> > Documentation/admin-guide/reporting-issues.rst contains a text written
> > to obsolete the good old reporting-bugs text. For now, the new docum
On 3/25/21 11:15 PM, Thorsten Leemhuis wrote:
> On 26.03.21 07:13, Thorsten Leemhuis wrote:
>>
> mention if backporting is planed or considered too complex. If backporting was
planned
Konstantin Ryabitsev wrote:
> On Tue, Mar 23, 2021 at 09:30:33AM -0700, James Bottomley wrote:
> > > I think the bulk of user issues are going to be regressions. Although
> > > you may be in a better position to know for sure, but at least for
> > > me, wearing my "user" hat, the thing that gets m
On Tue, Mar 23, 2021 at 09:30:33AM -0700, James Bottomley wrote:
> > I think the bulk of user issues are going to be regressions. Although
> > you may be in a better position to know for sure, but at least for
> > me, wearing my "user" hat, the thing that gets me the most is
> > upgrading to a new
On 23.03.21 16:01, Konstantin Ryabitsev wrote:
> On Tue, 23 Mar 2021 at 04:58, Thorsten Leemhuis wrote:
>>> If we can
>>> actually get users to *read* it, I think it's going to save kernel
>>> developers a huge amount of time and frustration.
>> And users hopefully as well. But yes, making them r
On 23.03.21 19:11, Theodore Ts'o wrote:
> On Tue, Mar 23, 2021 at 09:57:57AM +0100, Thorsten Leemhuis wrote:
>> On 22.03.21 22:56, Theodore Ts'o wrote:
>>> On Mon, Mar 22, 2021 at 08:25:15PM +0100, Thorsten Leemhuis wrote:
I agree to the last point and yeah, maybe regressions are the more
On Tue, Mar 23, 2021 at 09:57:57AM +0100, Thorsten Leemhuis wrote:
> On 22.03.21 22:56, Theodore Ts'o wrote:
> > On Mon, Mar 22, 2021 at 08:25:15PM +0100, Thorsten Leemhuis wrote:
> >> I agree to the last point and yeah, maybe regressions are the more
> >> important problem we should work on – at l
On Tue, 2021-03-23 at 12:20 -0400, Steven Rostedt wrote:
> On Mon, 22 Mar 2021 20:25:15 +0100
> Thorsten Leemhuis wrote:
>
> > I agree to the last point and yeah, maybe regressions are the more
> > important problem we should work on – at least from the perspective
> > of kernel development. But
On Tue, 23 Mar 2021 at 04:58, Thorsten Leemhuis wrote:
> > If we can
> > actually get users to *read* it, I think it's going to save kernel
> > developers a huge amount of time and frustration.
>
> And users hopefully as well. But yes, making them read it is the
> problem. :-/
I've added a very
On Mon, Mar 22, 2021 at 1:25 PM Thorsten Leemhuis wrote:
>
>
>
> On 22.03.21 19:32, Linus Torvalds wrote:
> > On Mon, Mar 22, 2021 at 8:18 AM Thorsten Leemhuis
> > wrote:
> >>
> >> I even requested a
> >> "linux-regressi...@vger.kernel.org" a while later, but didn't hear
> >> anything back;
On 22.03.21 22:56, Theodore Ts'o wrote:
> On Mon, Mar 22, 2021 at 08:25:15PM +0100, Thorsten Leemhuis wrote:
>> I agree to the last point and yeah, maybe regressions are the more
>> important problem we should work on – at least from the perspective of
>> kernel development. But from the users per
On Mon, Mar 22, 2021 at 08:25:15PM +0100, Thorsten Leemhuis wrote:
> I agree to the last point and yeah, maybe regressions are the more
> important problem we should work on – at least from the perspective of
> kernel development. But from the users perspective (and
> reporting-issues.rst is writt
ly fly if the idea has buy-in from
>> at least the core kernel maintainers, to make sure they and the
>> developers actually use it. That's why I'm looking for feedback with
>> this mail and also CCed ksummit-discuss, as that's the easiest way to
>> make sure
On Mon, 2021-03-22 at 13:16 -0400, Konstantin Ryabitsev wrote:
> On Mon, Mar 22, 2021 at 04:18:14PM +0100, Thorsten Leemhuis wrote:
> > Note, there is a second reason why ksummit-discuss is CCed: another
> > reason why I want to create this new list is making it easier to
>
el maintainers, to make sure they and the
> developers actually use it. That's why I'm looking for feedback with
> this mail and also CCed ksummit-discuss, as that's the easiest way to
> make sure maintainers get aware of this idea and can raise their voice.
>
>
> Note, there i
On Wed, Dec 9, 2020 at 2:31 AM Dan Carpenter wrote:
>
> On Wed, Dec 09, 2020 at 12:54:30AM -0800, Joe Perches wrote:
> > On Wed, 2020-12-09 at 10:58 +0300, Dan Carpenter wrote:
> > > On Tue, Dec 08, 2020 at 09:01:49PM -0800, Joe Perches wrote:
> > > > On Tue, 2020-12-08 at 16:34 -0800, Kees Cook w
On Wed, Dec 09, 2020 at 12:54:30AM -0800, Joe Perches wrote:
> On Wed, 2020-12-09 at 10:58 +0300, Dan Carpenter wrote:
> > On Tue, Dec 08, 2020 at 09:01:49PM -0800, Joe Perches wrote:
> > > On Tue, 2020-12-08 at 16:34 -0800, Kees Cook wrote:
> > >
> > > > If not "Adjusted-by", what about "Tweaked-
On Wed, Dec 9, 2020 at 9:45 AM Vlastimil Babka wrote:
> On 12/9/20 8:58 AM, Dan Carpenter wrote:
> > On Tue, Dec 08, 2020 at 09:01:49PM -0800, Joe Perches wrote:
> >> On Tue, 2020-12-08 at 16:34 -0800, Kees Cook wrote:
> >>
> >> > If not "Adjusted-by", what about "Tweaked-by", "Helped-by",
> >> >
On Wed, 2020-12-09 at 10:58 +0300, Dan Carpenter wrote:
> On Tue, Dec 08, 2020 at 09:01:49PM -0800, Joe Perches wrote:
> > On Tue, 2020-12-08 at 16:34 -0800, Kees Cook wrote:
> >
> > > If not "Adjusted-by", what about "Tweaked-by", "Helped-by",
> > > "Corrected-by"?
> >
> > Improved-by: / Enhance
On 12/9/20 8:58 AM, Dan Carpenter wrote:
> On Tue, Dec 08, 2020 at 09:01:49PM -0800, Joe Perches wrote:
>> On Tue, 2020-12-08 at 16:34 -0800, Kees Cook wrote:
>>
>> > If not "Adjusted-by", what about "Tweaked-by", "Helped-by",
>> > "Corrected-by"?
>>
>> Improved-by: / Enhanced-by: / Revisions-by:
On Tue, Dec 08, 2020 at 09:01:49PM -0800, Joe Perches wrote:
> On Tue, 2020-12-08 at 16:34 -0800, Kees Cook wrote:
>
> > If not "Adjusted-by", what about "Tweaked-by", "Helped-by",
> > "Corrected-by"?
>
> Improved-by: / Enhanced-by: / Revisions-by:
>
I don't think we should give any credit for
On Tue, 2020-12-08 at 16:34 -0800, Kees Cook wrote:
> If not "Adjusted-by", what about "Tweaked-by", "Helped-by",
> "Corrected-by"?
Improved-by: / Enhanced-by: / Revisions-by:
Or simply don't use anything but a link to the conversion thread
like Konstantin suggested.
I still want to know what
On Thu, Dec 03, 2020 at 07:30:44PM +0100, Greg KH wrote:
> On Thu, Dec 03, 2020 at 12:40:47PM +0200, Leon Romanovsky wrote:
> > On Thu, Dec 03, 2020 at 10:36:56AM +0100, Geert Uytterhoeven wrote:
> > > On Thu, Dec 3, 2020 at 10:35 AM Leon Romanovsky wrote:
> > > > On Wed, Dec 02, 2020 at 08:02:27P
E-Mail: dr2987...@gmail.com
email:kraymon...@aol.com
infocar...@aim.com
On Thu, Dec 03, 2020 at 12:43:52AM +0100, Vlastimil Babka wrote:
>
> there was a bit of debate on Twitter about this, so I thought I would bring it
> here. Imagine a scenario where patch sits as a commit in -next and there's a
> bug
> report or fix, possibly by a bot or with some static analysis.
On Thu, 2020-12-03 at 14:17 -0500, Konstantin Ryabitsev wrote:
> On Thu, Dec 03, 2020 at 08:55:54AM -0800, Joe Perches wrote:
> > Perhaps automate a mechanism to capture that information as
> > git notes for the patches when applied.
>
> Git notes have a limited usefulness for this -- they are ind
On Thu, 2020-12-03 at 13:52 -0500, Matthew Wilcox wrote:
> It's not so much "clean history" that's the desire. It's "don't leave
> landmines for git bisect".
... top posting?
Well functional git bisect and show the evolution of the patch aren't
mutually exclusive. Plus our current clean history
On Thu, 2020-12-03 at 14:17 -0500, Konstantin Ryabitsev wrote:
> On Thu, Dec 03, 2020 at 08:55:54AM -0800, Joe Perches wrote:
> > Perhaps automate a mechanism to capture that information as
> > git notes for the patches when applied.
>
> Git notes have a limited usefulness for this -- they are ind
On Thu, Dec 03, 2020 at 08:55:54AM -0800, Joe Perches wrote:
> Perhaps automate a mechanism to capture that information as
> git notes for the patches when applied.
Git notes have a limited usefulness for this -- they are indeed part of
the repository, but they aren't replicated unless someone do
On Thu, Dec 03, 2020 at 07:30:44PM +0100, Greg KH wrote:
> On Thu, Dec 03, 2020 at 12:40:47PM +0200, Leon Romanovsky wrote:
> > On Thu, Dec 03, 2020 at 10:36:56AM +0100, Geert Uytterhoeven wrote:
> > > On Thu, Dec 3, 2020 at 10:35 AM Leon Romanovsky wrote:
> > > > On Wed, Dec 02, 2020 at 08:02:27P
On Thu, Dec 03, 2020 at 12:40:47PM +0200, Leon Romanovsky wrote:
> On Thu, Dec 03, 2020 at 10:36:56AM +0100, Geert Uytterhoeven wrote:
> > On Thu, Dec 3, 2020 at 10:35 AM Leon Romanovsky wrote:
> > > On Wed, Dec 02, 2020 at 08:02:27PM -0800, Dan Williams wrote:
> > > > On Wed, Dec 2, 2020 at 3:44
On Thu, 2020-12-03 at 05:58 -0800, James Bottomley wrote:
> So there are two embedded questions here: firstly, should we be as
> wedded to clean history as we are, because showing the evolution would
> simply solve this? Secondly, if we are agreed on clean history, how
> can we make engagement via
On Thu, 2020-12-03 at 00:43 +0100, Vlastimil Babka wrote:
> Hi,
>
> there was a bit of debate on Twitter about this, so I thought I would
> bring it here. Imagine a scenario where patch sits as a commit in
> -next and there's a bug report or fix, possibly by a bot or with some
> static analysis. T
On Thu, 3 Dec 2020, Dan Carpenter wrote:
> I'd like a "Fixes-from: Name email" tag for when someone spots a bug in
> a patch.
>
> I think we should not give credit for style complaints, because those
> are their own reward and we already have enough bike shedding.
I agree with Dan, although I'
On Thu, Dec 03, 2020 at 10:36:56AM +0100, Geert Uytterhoeven wrote:
> On Thu, Dec 3, 2020 at 10:35 AM Leon Romanovsky wrote:
> > On Wed, Dec 02, 2020 at 08:02:27PM -0800, Dan Williams wrote:
> > > On Wed, Dec 2, 2020 at 3:44 PM Vlastimil Babka wrote:
> > > > there was a bit of debate on Twitter a
I'd like a "Fixes-from: Name email" tag for when someone spots a bug in
a patch.
I think we should not give credit for style complaints, because those
are their own reward and we already have enough bike shedding.
regards,
dan carpenter
On Thu, Dec 3, 2020 at 10:35 AM Leon Romanovsky wrote:
> On Wed, Dec 02, 2020 at 08:02:27PM -0800, Dan Williams wrote:
> > On Wed, Dec 2, 2020 at 3:44 PM Vlastimil Babka wrote:
> > > there was a bit of debate on Twitter about this, so I thought I would
> > > bring it
> > > here. Imagine a scenar
On Wed, Dec 02, 2020 at 08:02:27PM -0800, Dan Williams wrote:
> On Wed, Dec 2, 2020 at 3:44 PM Vlastimil Babka wrote:
> >
> > Hi,
> >
> > there was a bit of debate on Twitter about this, so I thought I would bring
> > it
> > here. Imagine a scenario where patch sits as a commit in -next and there
On Wed, Dec 2, 2020 at 3:44 PM Vlastimil Babka wrote:
>
> Hi,
>
> there was a bit of debate on Twitter about this, so I thought I would bring it
> here. Imagine a scenario where patch sits as a commit in -next and there's a
> bug
> report or fix, possibly by a bot or with some static analysis. Th
On 8/3/20 5:36 PM, Jonathan Corbet wrote:
The election for the Linux Foundation Technical Advisory Board (TAB) will
be held virtually during the 2020 Kernel Summit and Linux Plumbers
Conference, August 24-28 2020. Nominations for candidates interested in
serving on the TAB are currently being
On Thu, 2020-08-13 at 10:35 -0400, Laura Abbott wrote:
> The voting itself will be taking place during the week of Linux
> Plumbers/Kernel summit, August 24-28. Keep an eye out for the
> ballot during that time period. We'll send out another e-mail
> when the ballots go out.
OK, thanks for the in
On 8/13/20 10:31 AM, Johannes Berg wrote:
Hi Laura,
Seeing your reminder reminded me :)
We will be using the electronic voting method that we used in 2019. All
Linux Plumbers Attendees will automatically receive a ballot. Anyone
who is otherwise eligible to vote should e-mail
tab-electi...@lis
Hi Laura,
Seeing your reminder reminded me :)
> We will be using the electronic voting method that we used in 2019. All
> Linux Plumbers Attendees will automatically receive a ballot. Anyone
> who is otherwise eligible to vote should e-mail
> tab-electi...@lists.linuxfoundation.org to request a
ike
> > > > and I run, but I suppose it also makes sense to discuss it on the
> > > > ksummit-discuss mailing list (cross-posted to linux-arch and lkml) as
> > > > well
> > > > even if we don't discuss it at the main ksummit track.
> > >
On Wed 2020-08-05 20:50:43, Geert Uytterhoeven wrote:
> Hi Pavel,
>
> On Wed, Aug 5, 2020 at 7:26 PM Pavel Machek wrote:
> > > I have submitted the below as a topic for the linux/arch/* MC that Mike
> > > and I run, but I suppose it also makes sense to discuss it o
Hi Pavel,
On Wed, Aug 5, 2020 at 7:26 PM Pavel Machek wrote:
> > I have submitted the below as a topic for the linux/arch/* MC that Mike
> > and I run, but I suppose it also makes sense to discuss it on the
> > ksummit-discuss mailing list (cross-posted to linux-arch and lkml
On Fri, Jul 31, 2020 at 09:57:41PM +, Bird, Tim wrote:
> > -Original Message-
> > From: j...@joshtriplett.org
> >
> > On Fri, Jul 31, 2020 at 05:00:12PM +0200, Arnd Bergmann wrote:
> > > The majority of the code in the kernel deals with hardware that was made
> > > a long time ago, and
> -Original Message-
> From: j...@joshtriplett.org
>
> On Fri, Jul 31, 2020 at 05:00:12PM +0200, Arnd Bergmann wrote:
> > The majority of the code in the kernel deals with hardware that was made
> > a long time ago, and we are regularly discussing which of those bits are
> > still needed.
On Fri, Jul 31, 2020 at 05:00:12PM +0200, Arnd Bergmann wrote:
> The majority of the code in the kernel deals with hardware that was made
> a long time ago, and we are regularly discussing which of those bits are
> still needed. In some cases (e.g. 20+ year old RISC workstation support),
> there ar
On Tue, Jul 28, 2020 at 12:44 AM Bird, Tim wrote:
>
> > -Original Message-
> > From: Laura Abbott
> >
> > On behalf of the Linux Foundation Technical Advisory Board (TAB), I'd
> > like to announce the voting procedures for the 2020 TAB elections.
> > The pool of eligible voters will consi
> -Original Message-
> From: Laura Abbott
>
> On behalf of the Linux Foundation Technical Advisory Board (TAB), I'd
> like to announce the voting procedures for the 2020 TAB elections.
> The pool of eligible voters will consist of the following:
>
> 1) All attendees of the Linux Plumbers
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 proposa
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
x27;
> +
> +Recommended replacements for 'blacklist/whitelist' are:
> +'denylist / allowlist'
> +'blocklist / passlist'
> +
> +Exceptions for introducing new usage is to maintain a userspace ABI/API,
> +or when updating code f
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 / allowlist'
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 and
trying to understand the
> > code.
>
> I think waiting for specs may result in long delays, we all know how
> 'fast' spec bodies work!
>
> Putting my soundwire maintainer hat, I see more than 1K uses of 'slave'
> in the subsystem due to MIPI defined terms of SoundWire Master/Slave, so
> I am planning to replace that and not wait for MIPI to update the spec.
Sounds good.
> A similar approach where we discuss with relevant stakeholder and arrive
> at replacement terms and swap them would be great
Right, just like any other coding-style cleanup, stage it the way that
makes the most sense for the subsystem you maintain.
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 notice
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,
> > > > D
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 'blacklist/whitelis
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'
> > > +'blocklist
ds
>
> Currently I'm replacing the former with "Foo is in denylist", but not
In the denylist?
julia
> sure about the latter case. I thought Kees mentioned about this, but
> don't remember the proposal...
>
> In anyway, I'm for the action:
>
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
; them would just make harder for anyone trying to understand the
> code.
I think waiting for specs may result in long delays, we all know how
'fast' spec bodies work!
Putting my soundwire maintainer hat, I see more than 1K uses of 'slave'
in the subsystem due to MIPI define
; +'director / performer'
> +
> +Recommended replacements for 'blacklist/whitelist' are:
> +'denylist / allowlist'
> +'blocklist / passlist'
> +
> +Exceptions for introducing new usage is to maintain a userspace AB
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:
> http://lore.kernel.org/r/159389297140.
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 blacklist/wh
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 co
>>> 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 do
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 blacklist/white
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 provided.
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.
> > W
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 under
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 word,
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 computin
otocol
+specification that mandates those terms. For new specifications
+translate specification usage of the terminology to the kernel coding
+standard where possible.
5) Typedefs
---
_______
Ksummit-discuss mailing list
ksummit-disc...@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
27;
> +'leader / follower'
> +'director / performer'
> +
> +Recommended replacements for 'blacklist/whitelist' are:
> +'denylist / allowlist'
> +'blocklist / passlist'
> +
> +Exceptions for introducing new usage is
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:
> http://lore.kernel.org/r/159389297140.22107
connotation of
> +'impermissible/permissible' does not support inclusion.
> +
> +Inclusion == global developer community efficiency.
> diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
> index f07c9250c3ac..ed861f6f8d25 100644
> --- a/Documentation/process/index.rst
> +++ b/Documentation/process/index.rst
> @@ -27,6 +27,7 @@ Below are the essential guides that every developer should
> read.
> submitting-patches
> programming-language
> coding-style
> + inclusive-terminology
> maintainer-pgp-guide
> email-clients
> kernel-enforcement-statement
>
> ___
> Ksummit-discuss mailing list
> ksummit-disc...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
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:
http://lore.kernel.org/r/159389297140.2210796.13590142254668787525.st..
telist' are: 'denylist/allowlist' or
> +'blocklist/passlist'.
> +
> +Exceptions for introducing new usage is to maintain a userspace ABI/API,
> +or when updating code for an existing (as of 2020) hardware or protocol
> +specification that mandates those terms. For new specifications
> +translate specification usage of the terminology to the kernel coding
> +standard where possible.
>
> 5) Typedefs
> ---
>
> ___
> Ksummit-discuss mailing list
> ksummit-disc...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
s in the lore archives if the
> > arguments are needed for future debates, but otherwise no
> > pressing
> > need to carry it in the tree (Linus, James)
Acked-by: James Bottomley
> Where did Linus publicly state this was unnecessary?
https://lists.linuxfoundation.org/pipermail/tech-board-discuss/2020-July/000412.html
James
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 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 termi
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 h
> 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 bla
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 fall
1 - 100 of 1589 matches
Mail list logo
