[PATCH 000/141] Fix fall-through warnings for Clang
Miguel Ojeda
miguel.ojeda.sandonis at gmail.com
Wed Nov 25 00:32:17 UTC 2020
On Mon, Nov 23, 2020 at 9:38 PM James Bottomley
<James.Bottomley at hansenpartnership.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
More information about the dri-devel
mailing list