From: Jeff Layton <jlayton@kernel.org>
To: Mateusz Guzik <mjguzik@gmail.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>, Jan Kara <jack@suse.cz>,
Christoph Hellwig <hch@lst.de>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] vfs: remove externs from fs.h on functions modified by i_ino widening
Date: Sat, 07 Mar 2026 13:05:16 -0500 [thread overview]
Message-ID: <ca823a5d56ff4c68fd4f17c2eaab51ed04d6b01e.camel@kernel.org> (raw)
In-Reply-To: <vuorddxuncggijjthaeilz26jd6tnbgf6wjicv3n3pt52ceyv2@fijkpocwutaw>
On Fri, 2026-03-06 at 23:17 +0100, Mateusz Guzik wrote:
> On Fri, Mar 06, 2026 at 08:27:01AM -0500, Jeff Layton wrote:
> > Christoph says, in response to one of the patches in the i_ino widening
> > series, which changes the prototype of several functions in fs.h:
> >
> > "Can you please drop all these pointless externs while you're at it?"
> >
> > Remove extern keyword from functions touched by that patch (and a few
> > that happened to be nearby).
> >
>
> Is there a reason to not straight up whack the keyword from *all* funcs in
> the file?
We could but that makes merge conflicts for backporters.
In this case I'm already touching these function prototypes (well, most
of them anyway. I took some liberties with adjacent declarations).
Doing this in a limited fashion shouldn't be a huge burden on people
backporting since we're already changing this area of the file.
Certainly we could do more cleanup in there, but that makes it trickier
to backport later patches that touch fs.h to older kernels.
Ultimately, it's a judgement call though. A one-time "let's fix all of
the warts in fs.h" patch is not out of the question, IMO.
--
Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2026-03-07 18:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-06 13:27 Jeff Layton
2026-03-06 14:54 ` Christoph Hellwig
2026-03-06 22:17 ` Mateusz Guzik
2026-03-07 18:05 ` Jeff Layton [this message]
2026-03-07 5:31 ` Matthew Wilcox
2026-03-07 6:10 ` Darrick J. Wong
2026-03-07 18:00 ` Jeff Layton
2026-03-09 9:02 ` Christian Brauner
2026-03-07 17:57 ` Jeff Layton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ca823a5d56ff4c68fd4f17c2eaab51ed04d6b01e.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=brauner@kernel.org \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mjguzik@gmail.com \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®