* [PATCH] platform/x86: thinkpad_acpi: Fix bitwise vs. logical warning @ 2021-10-18 18:25 Nathan Chancellor 2021-10-18 18:34 ` Nick Desaulniers 2021-10-19 15:20 ` Hans de Goede 0 siblings, 2 replies; 9+ messages in thread From: Nathan Chancellor @ 2021-10-18 18:25 UTC (permalink / raw) To: Henrique de Moraes Holschuh, Hans de Goede, Mark Gross Cc: Nick Desaulniers, ibm-acpi-devel, platform-driver-x86, linux-kernel, llvm, Nathan Chancellor, Tor Vic A new warning in clang points out a use of bitwise OR with boolean expressions in this driver: drivers/platform/x86/thinkpad_acpi.c:9061:11: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical] else if ((strlencmp(cmd, "level disengaged") == 0) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ || drivers/platform/x86/thinkpad_acpi.c:9061:11: note: cast one or both operands to int to silence this warning 1 error generated. This should clearly be a logical OR so change it to fix the warning. Fixes: fe98a52ce754 ("ACPI: thinkpad-acpi: add sysfs support to fan subdriver") Link: https://github.com/ClangBuiltLinux/linux/issues/1476 Reported-by: Tor Vic <torvic9@mailbox.org> Signed-off-by: Nathan Chancellor <nathan@kernel.org> --- drivers/platform/x86/thinkpad_acpi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c index 07b9710d500e..7442c3bb446a 100644 --- a/drivers/platform/x86/thinkpad_acpi.c +++ b/drivers/platform/x86/thinkpad_acpi.c @@ -9058,7 +9058,7 @@ static int fan_write_cmd_level(const char *cmd, int *rc) if (strlencmp(cmd, "level auto") == 0) level = TP_EC_FAN_AUTO; - else if ((strlencmp(cmd, "level disengaged") == 0) | + else if ((strlencmp(cmd, "level disengaged") == 0) || (strlencmp(cmd, "level full-speed") == 0)) level = TP_EC_FAN_FULLSPEED; else if (sscanf(cmd, "level %d", &level) != 1) base-commit: 85303db36b6e170917a7bc6aae4898c31a5272a0 -- 2.33.1.637.gf443b226ca ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] platform/x86: thinkpad_acpi: Fix bitwise vs. logical warning 2021-10-18 18:25 [PATCH] platform/x86: thinkpad_acpi: Fix bitwise vs. logical warning Nathan Chancellor @ 2021-10-18 18:34 ` Nick Desaulniers 2021-10-18 19:41 ` Linus Torvalds 2021-10-19 15:20 ` Hans de Goede 1 sibling, 1 reply; 9+ messages in thread From: Nick Desaulniers @ 2021-10-18 18:34 UTC (permalink / raw) To: Nathan Chancellor, Linus Torvalds Cc: Henrique de Moraes Holschuh, Hans de Goede, Mark Gross, ibm-acpi-devel, platform-driver-x86, linux-kernel, llvm, Tor Vic On Mon, Oct 18, 2021 at 11:26 AM Nathan Chancellor <nathan@kernel.org> wrote: > > A new warning in clang points out a use of bitwise OR with boolean > expressions in this driver: > > drivers/platform/x86/thinkpad_acpi.c:9061:11: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical] > else if ((strlencmp(cmd, "level disengaged") == 0) | > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > || > drivers/platform/x86/thinkpad_acpi.c:9061:11: note: cast one or both operands to int to silence this warning > 1 error generated. > > This should clearly be a logical OR so change it to fix the warning. > > Fixes: fe98a52ce754 ("ACPI: thinkpad-acpi: add sysfs support to fan subdriver") > Link: https://github.com/ClangBuiltLinux/linux/issues/1476 > Reported-by: Tor Vic <torvic9@mailbox.org> > Signed-off-by: Nathan Chancellor <nathan@kernel.org> LGTM, thanks for the patch! I guess this would be the first "interesting" case this warning has found in kernel sources? Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> > --- > drivers/platform/x86/thinkpad_acpi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c > index 07b9710d500e..7442c3bb446a 100644 > --- a/drivers/platform/x86/thinkpad_acpi.c > +++ b/drivers/platform/x86/thinkpad_acpi.c > @@ -9058,7 +9058,7 @@ static int fan_write_cmd_level(const char *cmd, int *rc) > > if (strlencmp(cmd, "level auto") == 0) > level = TP_EC_FAN_AUTO; > - else if ((strlencmp(cmd, "level disengaged") == 0) | > + else if ((strlencmp(cmd, "level disengaged") == 0) || > (strlencmp(cmd, "level full-speed") == 0)) > level = TP_EC_FAN_FULLSPEED; > else if (sscanf(cmd, "level %d", &level) != 1) > > base-commit: 85303db36b6e170917a7bc6aae4898c31a5272a0 > -- > 2.33.1.637.gf443b226ca > -- Thanks, ~Nick Desaulniers ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] platform/x86: thinkpad_acpi: Fix bitwise vs. logical warning 2021-10-18 18:34 ` Nick Desaulniers @ 2021-10-18 19:41 ` Linus Torvalds 2021-10-18 20:14 ` Nick Desaulniers 0 siblings, 1 reply; 9+ messages in thread From: Linus Torvalds @ 2021-10-18 19:41 UTC (permalink / raw) To: Nick Desaulniers Cc: Nathan Chancellor, Henrique de Moraes Holschuh, Hans de Goede, Mark Gross, ibm-acpi-devel, platform-driver-x86, Linux Kernel Mailing List, llvm, Tor Vic On Mon, Oct 18, 2021 at 8:34 AM Nick Desaulniers <ndesaulniers@google.com> wrote: > > LGTM, thanks for the patch! I guess this would be the first > "interesting" case this warning has found in kernel sources? The patch looks obviously correct (tm), but I'm not convinced that the warning is actually all that interesting. The thing is, using bitwise operators for booleans is _exactly_ the same as using logical ones as long as there are no side effects. In fact, any compiler worth its salt will already convert some cases between the two as an optimization just as part of code generation. Of course, that "as long as there are no side effects" is the big thing - then the short-circuiting of the actual logical operations clearly matters. But that wasn't actually the case in this situation (or in the kvm situation elsewhere). So in both of these cases, the difference between "|" and "||" ends up purely being a hint to the compiler. In this case, even if there are no side effects, it's clearly pointless to do the second strlencmp() if the first one already matched, and the "||" is unquestionably the right hint (and honestly, most compilers probably wouldn't even be able to tell "no side effects" because it's a fairly complex expression - but since it's inlined and uses compiler intrinsics, the compiler _might_ actually be able to see that the two are equivalent). But no, I don't think that warning is very interesting. In fact, the warning might be overall detrimental, in case the hints were intentional (like the kvm case - although I'm not convinced the kvm hinting was actually meaningful). Linus ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] platform/x86: thinkpad_acpi: Fix bitwise vs. logical warning 2021-10-18 19:41 ` Linus Torvalds @ 2021-10-18 20:14 ` Nick Desaulniers 2021-10-19 3:38 ` Linus Torvalds 0 siblings, 1 reply; 9+ messages in thread From: Nick Desaulniers @ 2021-10-18 20:14 UTC (permalink / raw) To: Linus Torvalds Cc: Nathan Chancellor, Henrique de Moraes Holschuh, Hans de Goede, Mark Gross, ibm-acpi-devel, platform-driver-x86, Linux Kernel Mailing List, llvm, Tor Vic On Mon, Oct 18, 2021 at 12:41 PM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > On Mon, Oct 18, 2021 at 8:34 AM Nick Desaulniers > <ndesaulniers@google.com> wrote: > > > > LGTM, thanks for the patch! I guess this would be the first > > "interesting" case this warning has found in kernel sources? > > The patch looks obviously correct (tm), but I'm not convinced that the > warning is actually all that interesting. > > The thing is, using bitwise operators for booleans is _exactly_ the > same as using logical ones as long as there are no side effects. Right, the patch that added the warning explicitly checks for side effects. https://reviews.llvm.org/D108003 https://lore.kernel.org/lkml/20211018193101.2340261-1-nathan@kernel.org/ is another example that I would point to in favor of the error. -- Thanks, ~Nick Desaulniers ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] platform/x86: thinkpad_acpi: Fix bitwise vs. logical warning 2021-10-18 20:14 ` Nick Desaulniers @ 2021-10-19 3:38 ` Linus Torvalds 2021-10-19 5:00 ` Nathan Chancellor 0 siblings, 1 reply; 9+ messages in thread From: Linus Torvalds @ 2021-10-19 3:38 UTC (permalink / raw) To: Nick Desaulniers Cc: Nathan Chancellor, Henrique de Moraes Holschuh, Hans de Goede, Mark Gross, ibm-acpi-devel, platform-driver-x86, Linux Kernel Mailing List, llvm, Tor Vic On Mon, Oct 18, 2021 at 10:14 AM Nick Desaulniers <ndesaulniers@google.com> wrote: > > Right, the patch that added the warning explicitly checks for side effects. Well, it's a bit questionable. The "side effects" are things like any pointer dereference, because it could fault, but if you know that isn't an issue, then clang basically ends up complaining about code that is perfectly fine. Maybe it was written that way on purpose, like the kvm code. Now, it's probably not worth keeping that "bitops of booleans" logic - if it is a noticeable optimization, it's generally something that the compiler should do for us, but basically clang is warning about perfectly valid code. And what I find absolutely disgusting is the suggested "fix" that clang gives you. If the warning said "maybe you meant to use a logical or (||)", then that would be one thing. But what clang suggests as the "fix" for the warning is just bad coding practice. If a warning fix involves making the code uglier, then the warning fix is wrong. This is not the first time we've had compilers suggesting garbage. Gcc used to suggest (perhaps still does) the "extra parenthesis" for "assignment used as a truth value" situation. Which is - once again - disgusting garbage. Writing code like if (a = b) .. is bad and error prone. But the suggestion to "fix" the warning with if ((a = b)) .. is just completely unacceptably stupid, and is just BAD CODE. The proper fix might be to write it like if ((a = b) != 0) ... which at least makes the truth value part explicit - in ways that a silly double parenthesis does not. Or, better yet, write it as a = b; if (a) .. instead, which is legible and fine. The clang suggestion to add a cast to 'int' to avoid the warning is the same kind of "write bad code" suggestion. Just don't do it. Linus ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] platform/x86: thinkpad_acpi: Fix bitwise vs. logical warning 2021-10-19 3:38 ` Linus Torvalds @ 2021-10-19 5:00 ` Nathan Chancellor 2021-10-19 6:27 ` Linus Torvalds 0 siblings, 1 reply; 9+ messages in thread From: Nathan Chancellor @ 2021-10-19 5:00 UTC (permalink / raw) To: Linus Torvalds Cc: Nick Desaulniers, Henrique de Moraes Holschuh, Hans de Goede, Mark Gross, ibm-acpi-devel, platform-driver-x86, Linux Kernel Mailing List, llvm, Tor Vic On Mon, Oct 18, 2021 at 05:38:09PM -1000, Linus Torvalds wrote: > On Mon, Oct 18, 2021 at 10:14 AM Nick Desaulniers > <ndesaulniers@google.com> wrote: > > > > Right, the patch that added the warning explicitly checks for side effects. > > Well, it's a bit questionable. The "side effects" are things like any > pointer dereference, because it could fault, but if you know that > isn't an issue, then clang basically ends up complaining about code > that is perfectly fine. Maybe it was written that way on purpose, like > the kvm code. > > Now, it's probably not worth keeping that "bitops of booleans" logic - > if it is a noticeable optimization, it's generally something that the > compiler should do for us, but basically clang is warning about > perfectly valid code. > > And what I find absolutely disgusting is the suggested "fix" that > clang gives you. > > If the warning said "maybe you meant to use a logical or (||)", then > that would be one thing. But what clang suggests as the "fix" for the > warning is just bad coding practice. For what it's worth, the suggested fix is the '||' underneath the warning text: In file included from arch/x86/kvm/mmu/tdp_iter.c:5: arch/x86/kvm/mmu/spte.h:318:9: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical] return __is_bad_mt_xwr(rsvd_check, spte) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ || arch/x86/kvm/mmu/spte.h:318:9: note: cast one or both operands to int to silence this warning 1 error generated. Perhaps that hint should also be added to the warning text, like: In file included from arch/x86/kvm/mmu/tdp_iter.c:5: arch/x86/kvm/mmu/spte.h:318:9: error: use of bitwise '|' with boolean operands; did you mean logical '||'? [-Werror,-Wbitwise-instead-of-logical] return __is_bad_mt_xwr(rsvd_check, spte) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ || arch/x86/kvm/mmu/spte.h:318:9: note: cast one or both operands to int to silence this warning 1 error generated. It is late for me but I can push that change to the clang developers and see what they think tomorrow if that would help? Cheers, Nathan ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] platform/x86: thinkpad_acpi: Fix bitwise vs. logical warning 2021-10-19 5:00 ` Nathan Chancellor @ 2021-10-19 6:27 ` Linus Torvalds 2021-10-19 17:35 ` Nathan Chancellor 0 siblings, 1 reply; 9+ messages in thread From: Linus Torvalds @ 2021-10-19 6:27 UTC (permalink / raw) To: Nathan Chancellor Cc: Nick Desaulniers, Henrique de Moraes Holschuh, Hans de Goede, Mark Gross, ibm-acpi-devel, platform-driver-x86, Linux Kernel Mailing List, llvm, Tor Vic On Mon, Oct 18, 2021 at 7:00 PM Nathan Chancellor <nathan@kernel.org> wrote: > > For what it's worth, the suggested fix is the '||' underneath the > warning text: > > In file included from arch/x86/kvm/mmu/tdp_iter.c:5: > arch/x86/kvm/mmu/spte.h:318:9: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical] > return __is_bad_mt_xwr(rsvd_check, spte) | > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > || > arch/x86/kvm/mmu/spte.h:318:9: note: cast one or both operands to int to silence this warning > 1 error generated. Hmm. That's not at all obvious. The *much* bigger part is that note: cast one or both operands to int to silence this warning which is what I'm complaining about. That note should die. It should say "maybe you meant to use a logical or" or something like that. > Perhaps that hint should also be added to the warning text, like: > > In file included from arch/x86/kvm/mmu/tdp_iter.c:5: > arch/x86/kvm/mmu/spte.h:318:9: error: use of bitwise '|' with boolean operands; did you mean logical '||'? [-Werror,-Wbitwise-instead-of-logical] > return __is_bad_mt_xwr(rsvd_check, spte) | > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > || > arch/x86/kvm/mmu/spte.h:318:9: note: cast one or both operands to int to silence this warning I don't understand why you seem to continue to ignore the "note" message, which makes a completely crazy suggestion. Linus ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] platform/x86: thinkpad_acpi: Fix bitwise vs. logical warning 2021-10-19 6:27 ` Linus Torvalds @ 2021-10-19 17:35 ` Nathan Chancellor 0 siblings, 0 replies; 9+ messages in thread From: Nathan Chancellor @ 2021-10-19 17:35 UTC (permalink / raw) To: Linus Torvalds Cc: Nick Desaulniers, Linux Kernel Mailing List, llvm, Tor Vic, Dávid Bolvanský Trimming up the replies as we are not really talking about the x86 platform drivers warning anymore. On Mon, Oct 18, 2021 at 08:27:02PM -1000, Linus Torvalds wrote: > On Mon, Oct 18, 2021 at 7:00 PM Nathan Chancellor <nathan@kernel.org> wrote: > > > > For what it's worth, the suggested fix is the '||' underneath the > > warning text: > > > > In file included from arch/x86/kvm/mmu/tdp_iter.c:5: > > arch/x86/kvm/mmu/spte.h:318:9: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical] > > return __is_bad_mt_xwr(rsvd_check, spte) | > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > || > > arch/x86/kvm/mmu/spte.h:318:9: note: cast one or both operands to int to silence this warning > > 1 error generated. > > Hmm. That's not at all obvious. I agree, hence the question added to the warning. > The *much* bigger part is that > > note: cast one or both operands to int to silence this warning > > which is what I'm complaining about. That note should die. It should > say "maybe you meant to use a logical or" or something like that. > > > Perhaps that hint should also be added to the warning text, like: > > > > In file included from arch/x86/kvm/mmu/tdp_iter.c:5: > > arch/x86/kvm/mmu/spte.h:318:9: error: use of bitwise '|' with boolean operands; did you mean logical '||'? [-Werror,-Wbitwise-instead-of-logical] > > return __is_bad_mt_xwr(rsvd_check, spte) | > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > || > > arch/x86/kvm/mmu/spte.h:318:9: note: cast one or both operands to int to silence this warning > > I don't understand why you seem to continue to ignore the "note" > message, which makes a completely crazy suggestion. Sorry, I was not intentionally ignoring the note. As far as I understand it, it is fairly common for clang to offer a fix up in case the answer to the question of "did you mean to do this?" is "no" but also offer a way to shut the warning up in case the answer is "yes, I know what I am doing", hence the note about casting. Changing to logical OR is not always the answer, as something like int a, b, c; changed = foo(&a) | foo(&b) | foo(&c); if (changed) bar(a, b, c); no longer works. It could be changed to int a, b, c; changed = foo(&a); changed |= foo(&b); changed |= foo(&c); if (changed) baz(a, b, c); to make it clearer to both humans and the compiler that every call to foo() needs to happen and the results are being aggregated. With that, perhaps the note could be changed to something like: note: separate expressions with '|=' to silence this warning Although, that would require that the expression was being assigned to a variable, rather than being returned or used in a loop like the KVM one or this other one that is seen in fs/namei.c on big endian ARM configurations with CONFIG_DCACHE_WORD_ACCESS because has_zero() returns bool instead of unsigned long on little endian architectures: fs/namei.c:2149:13: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical] } while (!(has_zero(a, &adata, &constants) | has_zero(b, &bdata, &constants))); ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ || fs/namei.c:2149:13: note: cast one or both operands to int to silence this warning 1 warning generated. Perhaps the note should just be eliminated entirely so that developers can be left to try and figure out a way to silence it on their own or just rework the code to use logical OR or not use boolean types, I do not know. There was some discussion upstream around how the warning should be silenced during the warning's creation. I have added the author of the warning, David, to this thread to see if he has any insights. David, you can see the start of this thread here and follow along with the threading at the bottom: https://lore.kernel.org/r/CAHk-=wi7hUsTTcmPfZCkUEw51Y3ayq3JJxzFsNgodsxxDyk9Ww@mail.gmail.com/ Cheers, Nathan ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] platform/x86: thinkpad_acpi: Fix bitwise vs. logical warning 2021-10-18 18:25 [PATCH] platform/x86: thinkpad_acpi: Fix bitwise vs. logical warning Nathan Chancellor 2021-10-18 18:34 ` Nick Desaulniers @ 2021-10-19 15:20 ` Hans de Goede 1 sibling, 0 replies; 9+ messages in thread From: Hans de Goede @ 2021-10-19 15:20 UTC (permalink / raw) To: Nathan Chancellor, Henrique de Moraes Holschuh, Mark Gross Cc: Nick Desaulniers, ibm-acpi-devel, platform-driver-x86, linux-kernel, llvm, Tor Vic Hi, On 10/18/21 20:25, Nathan Chancellor wrote: > A new warning in clang points out a use of bitwise OR with boolean > expressions in this driver: > > drivers/platform/x86/thinkpad_acpi.c:9061:11: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical] > else if ((strlencmp(cmd, "level disengaged") == 0) | > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > || > drivers/platform/x86/thinkpad_acpi.c:9061:11: note: cast one or both operands to int to silence this warning > 1 error generated. > > This should clearly be a logical OR so change it to fix the warning. > > Fixes: fe98a52ce754 ("ACPI: thinkpad-acpi: add sysfs support to fan subdriver") > Link: https://github.com/ClangBuiltLinux/linux/issues/1476 > Reported-by: Tor Vic <torvic9@mailbox.org> > Signed-off-by: Nathan Chancellor <nathan@kernel.org> Thank you for your patch, I've applied this patch to my review-hans branch: https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans Note it will show up in my review-hans branch once I've pushed my local branch there, which might take a while. Once I've run some tests on this branch the patches there will be added to the platform-drivers-x86/for-next branch and eventually will be included in the pdx86 pull-request to Linus for the next merge-window. Regards, Hans > --- > drivers/platform/x86/thinkpad_acpi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/thinkpad_acpi.c > index 07b9710d500e..7442c3bb446a 100644 > --- a/drivers/platform/x86/thinkpad_acpi.c > +++ b/drivers/platform/x86/thinkpad_acpi.c > @@ -9058,7 +9058,7 @@ static int fan_write_cmd_level(const char *cmd, int *rc) > > if (strlencmp(cmd, "level auto") == 0) > level = TP_EC_FAN_AUTO; > - else if ((strlencmp(cmd, "level disengaged") == 0) | > + else if ((strlencmp(cmd, "level disengaged") == 0) || > (strlencmp(cmd, "level full-speed") == 0)) > level = TP_EC_FAN_FULLSPEED; > else if (sscanf(cmd, "level %d", &level) != 1) > > base-commit: 85303db36b6e170917a7bc6aae4898c31a5272a0 > ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-10-19 17:35 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-10-18 18:25 [PATCH] platform/x86: thinkpad_acpi: Fix bitwise vs. logical warning Nathan Chancellor 2021-10-18 18:34 ` Nick Desaulniers 2021-10-18 19:41 ` Linus Torvalds 2021-10-18 20:14 ` Nick Desaulniers 2021-10-19 3:38 ` Linus Torvalds 2021-10-19 5:00 ` Nathan Chancellor 2021-10-19 6:27 ` Linus Torvalds 2021-10-19 17:35 ` Nathan Chancellor 2021-10-19 15:20 ` Hans de Goede
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.