Date:   Wed, 25 Nov 2020 01:32:17 +0100
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     James Bottomley <James.Bottomley@...senpartnership.com>
Cc:     Kees Cook <keescook@...omium.org>,
        Jakub Kicinski <kuba@...nel.org>,
        "Gustavo A. R. Silva" <gustavoars@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        alsa-devel@...a-project.org, amd-gfx@...ts.freedesktop.org,
        bridge@...ts.linux-foundation.org, ceph-devel@...r.kernel.org,
        cluster-devel@...hat.com, coreteam@...filter.org,
        devel@...verdev.osuosl.org, dm-devel@...hat.com,
        drbd-dev@...ts.linbit.com, dri-devel@...ts.freedesktop.org,
        GR-everest-linux-l2@...vell.com, GR-Linux-NIC-Dev@...vell.com,
        intel-gfx@...ts.freedesktop.org, intel-wired-lan@...ts.osuosl.org,
        keyrings@...r.kernel.org, linux1394-devel@...ts.sourceforge.net,
        linux-acpi@...r.kernel.org, linux-afs@...ts.infradead.org,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-arm-msm@...r.kernel.org,
        linux-atm-general@...ts.sourceforge.net,
        linux-block@...r.kernel.org, linux-can@...r.kernel.org,
        linux-cifs@...r.kernel.org,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        linux-decnet-user@...ts.sourceforge.net,
        Ext4 Developers List <linux-ext4@...r.kernel.org>,
        linux-fbdev@...r.kernel.org, linux-geode@...ts.infradead.org,
        linux-gpio@...r.kernel.org, linux-hams@...r.kernel.org,
        linux-hwmon@...r.kernel.org, linux-i3c@...ts.infradead.org,
        linux-ide@...r.kernel.org, linux-iio@...r.kernel.org,
        linux-input <linux-input@...r.kernel.org>,
        linux-integrity@...r.kernel.org,
        linux-mediatek@...ts.infradead.org,
        Linux Media Mailing List <linux-media@...r.kernel.org>,
        linux-mmc@...r.kernel.org, Linux-MM <linux-mm@...ck.org>,
        linux-mtd@...ts.infradead.org, linux-nfs@...r.kernel.org,
        linux-rdma@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
        linux-scsi@...r.kernel.org, linux-sctp@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        linux-stm32@...md-mailman.stormreply.com,
        linux-usb@...r.kernel.org, linux-watchdog@...r.kernel.org,
        linux-wireless <linux-wireless@...r.kernel.org>,
        Network Development <netdev@...r.kernel.org>,
        netfilter-devel@...r.kernel.org, nouveau@...ts.freedesktop.org,
        op-tee@...ts.trustedfirmware.org, oss-drivers@...ronome.com,
        patches@...nsource.cirrus.com, rds-devel@....oracle.com,
        reiserfs-devel@...r.kernel.org, samba-technical@...ts.samba.org,
        selinux@...r.kernel.org, target-devel@...r.kernel.org,
        tipc-discussion@...ts.sourceforge.net,
        usb-storage@...ts.one-eyed-alien.net,
        virtualization@...ts.linux-foundation.org,
        wcn36xx@...ts.infradead.org,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        xen-devel@...ts.xenproject.org, linux-hardening@...r.kernel.org,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Nathan Chancellor <natechancellor@...il.com>,
        Miguel Ojeda <ojeda@...nel.org>, Joe Perches <joe@...ches.com>
Subject: Re: [PATCH 000/141] Fix fall-through warnings for Clang

On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
<James.Bottomley@...senpartnership.com> wrote:
>
> So you think a one line patch should take one minute to produce ... I
> really don't think that's grounded in reality.

No, I have not said that. Please don't put words in my mouth (again).

I have said *authoring* lines of *this* kind takes a minute per line.
Specifically: lines fixing the fallthrough warning mechanically and
repeatedly where the compiler tells you to, and doing so full-time for
a month.

For instance, take the following one from Gustavo. Are you really
saying it takes 12 minutes (your number) to write that `break;`?

diff --git a/drivers/gpu/drm/via/via_irq.c b/drivers/gpu/drm/via/via_irq.c
index 24cc445169e2..a3e0fb5b8671 100644
--- a/drivers/gpu/drm/via/via_irq.c
+++ b/drivers/gpu/drm/via/via_irq.c
@@ -364,6 +364,7 @@ int via_wait_irq(struct drm_device *dev, void
*data, struct drm_file *file_priv)
                irqwait->request.sequence +=
                        atomic_read(&cur_irq->irq_received);
                irqwait->request.type &= ~_DRM_VBLANK_RELATIVE;
+               break;
        case VIA_IRQ_ABSOLUTE:
                break;
        default:

>  I suppose a one line
> patch only takes a minute to merge with b4 if no-one reviews or tests
> it, but that's not really desirable.

I have not said that either. I said reviewing and merging those are
noise compared to any complex patch. Testing should be done by the
author comparing codegen.

> Part of what I'm trying to measure is the "and useful" bit because
> that's not a given.

It is useful since it makes intent clear. It also catches actual bugs,
which is even more valuable.

> Well, you know, subsystems are very different in terms of the amount of
> patches a maintainer has to process per release cycle of the kernel.
> If a maintainer is close to capacity, additional patches, however
> trivial, become a problem.  If a maintainer has spare cycles, trivial
> patches may look easy.

First of all, voluntary maintainers choose their own workload.
Furthermore, we already measure capacity in the `MAINTAINERS` file:
maintainers can state they can only handle a few patches. Finally, if
someone does not have time for a trivial patch, they are very unlikely
to have any time to review big ones.

> You seem to be saying that because you find it easy to merge trivial
> patches, everyone should.

Again, I have not said anything of the sort.

Cheers,
Miguel

Powered by blists - more mailing lists