[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260204190218.GA2193@sol>
Date: Wed, 4 Feb 2026 11:02:18 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: Matthew Wilcox <willy@...radead.org>
Cc: Christoph Hellwig <hch@....de>, Al Viro <viro@...iv.linux.org.uk>,
Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
David Sterba <dsterba@...e.com>, Theodore Ts'o <tytso@....edu>,
Jaegeuk Kim <jaegeuk@...nel.org>, Chao Yu <chao@...nel.org>,
Andrey Albershteyn <aalbersh@...hat.com>,
linux-fsdevel@...r.kernel.org, linux-btrfs@...r.kernel.org,
linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
fsverity@...ts.linux.dev
Subject: Re: fsverity speedup and memory usage optimization v5
On Wed, Feb 04, 2026 at 02:54:18PM +0000, Matthew Wilcox wrote:
> On Mon, Feb 02, 2026 at 01:14:23PM -0800, Eric Biggers wrote:
> > - Used the code formatting from 'git clang-format' in the cases where it
> > looks better than the ad-hoc formatting
>
> clang-format makes some bad choices.
>
> > static int ext4_mpage_readpages(struct inode *inode, struct fsverity_info *vi,
> > - struct readahead_control *rac, struct folio *folio)
> > + struct readahead_control *rac,
> > + struct folio *folio)
>
> Aligning to the opening bracket is one of them. If anything changes
> in a subsequent patch (eg function name, whether or not it's static,
> adding a function attribute like __must_check, converting the return
> type from int to bool), you have to eitheer break the formatting or
> needlessly change the lines which have the subsequent arguments.
>
> Also, you've consumed an extra line in this case. Just leave the
> two tab indent, it's actually easier to read.
Aligning to the opening bracket is the usual style as agreed on by the
kernel community. This should also be clear if you look at the existing
style in all the files this patchset touches. It's not done exclusively
but is the more common way. clang-format just follows that.
It's 2026. We generally shouldn't be formatting code manually. We have
better things to do.
If you're going to insist on ad-hoc formatting of argument lists, you'll
need to be more specific about where and how you want it to be done. It
certainly doesn't make sense in files that are already using the normal
style exclusively, for example.
- Eric
Powered by blists - more mailing lists