Linux filesystem development
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: Mateusz Guzik <mjguzik@gmail.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fs: remove stale log entries from fs/namei.c
Date: Thu, 3 Apr 2025 10:39:25 +0200	[thread overview]
Message-ID: <20250403-tunnel-lethargisch-810d83030763@brauner> (raw)
In-Reply-To: <CAGudoHF_Nfjq1nLZhMbFr3GJz-z=9Z4goacCgXbifxrQX7yiwA@mail.gmail.com>

On Tue, Apr 01, 2025 at 02:28:08PM +0200, Mateusz Guzik wrote:
> On Tue, Apr 1, 2025 at 12:49 PM Christian Brauner <brauner@kernel.org> wrote:
> >
> > On Tue, 01 Apr 2025 07:08:46 +0200, Mateusz Guzik wrote:
> > >
> >
> > I have zero attachment to these comments so I'm inclined to agree and
> > remove them. Please anyone who really really thinks we need them speak
> > up!
> 
> ouch man
> 
> this submission was a joke, which is why I only sent it to the list
> and skipped the maintainers as direct recipients
> 
> it *adds* the following:
> >  /*[Apr 1 2024 Mateusz Guzik] Removed stale log entries.
> 
> I can't tell if this actually landed because the url:
> > [1/1] fs: remove stale log entries from fs/namei.c
> >       https://git.kernel.org/vfs/vfs/c/3dddecbd2b47
> 
> says "bad object id" at the moment.
> 
> I very much support removal of this kind of commentary, but this could
> be very flamewar inducing and I did not want to spend time on a
> non-tech discussion about it.
> 
> However, if actually doing this, there is more to whack and I'll be
> happy to do a real submission with more files.
> 
> Even in this file alone:
> > /* In order to reduce some races, while at the same time doing additional
> > * checking and hopefully speeding things up, we copy filenames to the
> > * kernel data space before using them..
> 
> I think this comment also needs to get whacked. Copying the path is
> not optional.

I'm thoroughly confused how this would be a meaningful April fools joke?

The comments in that file are literally 20+ years old and no one has
ever bothered to add new updates there even though Al, Neil, Jeff,
myself and a lot of others probably rewrote that file a gazillion number
of times together or significantly or at least subtly changed the rules.

So should we have added comments to the top of the file each time?
And since we didn't does it really serve as an interesting historical log?

The proper place for that has been
Documentation/filesystems/{locking.rst,porting.rst,path_lookup.rst}
for a long time now.

The comments are historical artifacts. At best they serve as a
humble-brag about who massaged what. I venture a guess and think that no
one needs that comment to figure out who has made a significant impact
here.

  reply	other threads:[~2025-04-03  8:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-01  5:08 [PATCH] fs: remove stale log entries from fs/namei.c Mateusz Guzik
2025-04-01 10:49 ` Christian Brauner
2025-04-01 12:28   ` Mateusz Guzik
2025-04-03  8:39     ` Christian Brauner [this message]
2025-04-03 10:39       ` Mateusz Guzik
2025-04-03 10:40         ` Mateusz Guzik

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=20250403-tunnel-lethargisch-810d83030763@brauner \
    --to=brauner@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjguzik@gmail.com \
    /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