Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sat, 29 Jan 2022 10:45:53 +1100 (AEDT)
From:   Finn Thain <fthain@linux-m68k.org>
To:     Tom Rix <trix@redhat.com>
cc:     Joe Perches <joe@perches.com>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Miguel Ojeda <ojeda@kernel.org>, kashyap.desai@broadcom.com,
        sumit.saxena@broadcom.com, shivasharan.srikanteshwara@broadcom.com,
        jejb@linux.ibm.com, martin.petersen@oracle.com, nathan@kernel.org,
        megaraidlinux.pdl@broadcom.com, linux-scsi@vger.kernel.org,
        linux-kernel@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH] scsi: megaraid: cleanup formatting of megaraid
In-Reply-To: <0567fce4-256a-e1b1-dc66-221ba97153d5@redhat.com>
Message-ID: <56b761a-6cf9-23ab-c849-eff27e5e831e@linux-m68k.org>
References: <20220127151945.1244439-1-trix@redhat.com> <953eb015-4b78-f7b-5dc1-6491c6bf27e@linux-m68k.org> <CAKwvOdnWHVV+3s8SO=Q8FfZ7hVekRVDL5q+7CwAk_z44xaex8w@mail.gmail.com> <fb308f51-f16b-3d9b-80c2-180940236b00@redhat.com> <5554a75f65fddab4de60d61fd503fe73773dafbb.camel@perches.com>
 <c801989d-5f3e-84d2-24a0-7022be70da98@redhat.com> <7bff2de309384b7c9ee71ad90881d1e0bbe0a781.camel@perches.com> <0567fce4-256a-e1b1-dc66-221ba97153d5@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Precedence: bulk

On Fri, 28 Jan 2022, Tom Rix wrote:

> A testsuite for the fixers may help with churn
> 
> Any interest or thought on organization ?
> 

Here's one way:

1. Identify some source files that are exemplary (i.e. good style).
2. Run a new script to introduce style mistakes into those files.
3. Run the Reformatter Under Test on those files.
4. Compare the output with the original files.

But that's not sufficient to prevent more style patches (churn). We still 
need a way to avoid wasting everyone's time writing, submitting, reviewing 
and merging the inevitably incomplete style patches that may contain 
regressions and cause conflicts.

The tooling I would like to see is not a script to introduce style 
mistakes but an editor for binaries, such that C is not the "source" at 
all but only an ephemeral representation to make it easier for humans to 
effect changes to binaries (and debug info, commentary etc.)

Nonetheless, perfecting the clang-format tool is a good step towards a 
better workflow, which I described once before. 
https://lore.kernel.org/r/alpine.LNX.2.23.453.2010281344120.31@nippy.intranet/