From: Al Viro <viro@zeniv.linux.org.uk>
To: Thomas Bertschinger <tahbertschinger@gmail.com>
Cc: io-uring@vger.kernel.org, axboe@kernel.dk,
linux-fsdevel@vger.kernel.org, brauner@kernel.org,
linux-nfs@vger.kernel.org
Subject: Re: [PATCH 04/10] fhandle: create do_filp_path_open() helper
Date: Thu, 11 Sep 2025 01:53:12 +0100 [thread overview]
Message-ID: <20250911005312.GU31600@ZenIV> (raw)
In-Reply-To: <20250910214927.480316-5-tahbertschinger@gmail.com>
On Wed, Sep 10, 2025 at 03:49:21PM -0600, Thomas Bertschinger wrote:
> This pulls the code for opening a file, after its handle has been
> converted to a struct path, into a new helper function.
>
> This function will be used by io_uring once io_uring supports
> open_by_handle_at(2).
Not commenting on the rest of patchset, but...
Consider the choice of name NAKed with extreme prejudice. "filp"
thing should die; please, do not introduce more instances.
It has crawled out of Minix guts, where AST had been tasteless enough
to call a structure the represents an open file (which is called struct
file on all Unices, Linux included) "struct filp" instead, the identifier
standing for "file and position", nevermind that he did include more
state than that - the damn thing (in OSD&I appendix) is
struct filp {
mask_bits filp_mode; /* RW bits, telling how file is opened */
int filp_count; /* how many file descriptors share this slot? */
struct inode *filp_ino; /* pointer to the inode */
file_pos filp_pos; /* file position */
}
Linus used "struct file" from the very beginning; unfortunately, if you
grep for filp in 0.01 you'll see a plenty of those - in form of
0.01:fs/file_dev.c:int file_write(struct m_inode * inode, struct file * filp, char * buf, int count)
as well as
0.01:fs/ioctl.c: struct file * filp;
0.01:fs/ioctl.c: if (fd >= NR_OPEN || !(filp = current->filp[fd]))
which was both inconsistent *and* resembling hungarian notation just
enough to confuse (note that in the original that 'p' does *NOT* stand for
"pointer" - it's "current IO position"). Unfortunately, it was confusing
enough to stick around; at some point it even leaked into function names
(filp_open(); that one is my fault - sorry for that brainfart).
Let's not propagate that wart any further, please. If you are opening a file,
put "file" in the identifier.
next prev parent reply other threads:[~2025-09-11 0:53 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-10 21:49 [PATCHSET RFC v2 00/10] add support for name_to, open_by_handle_at() to io_uring Thomas Bertschinger
2025-09-10 21:49 ` [PATCH 01/10] fhandle: create helper for name_to_handle_at(2) Thomas Bertschinger
2025-09-11 12:06 ` Amir Goldstein
2025-09-10 21:49 ` [PATCH 02/10] io_uring: add support for IORING_OP_NAME_TO_HANDLE_AT Thomas Bertschinger
2025-09-10 21:49 ` [PATCH 03/10] fhandle: helper for allocating, reading struct file_handle Thomas Bertschinger
2025-09-11 12:15 ` Amir Goldstein
2025-09-11 15:31 ` Thomas Bertschinger
2025-09-11 15:54 ` Amir Goldstein
2025-09-10 21:49 ` [PATCH 04/10] fhandle: create do_filp_path_open() helper Thomas Bertschinger
2025-09-11 0:53 ` Al Viro [this message]
2025-09-11 12:21 ` Amir Goldstein
2025-09-10 21:49 ` [PATCH 05/10] fhandle: make do_filp_path_open() take struct open_flags Thomas Bertschinger
2025-09-10 21:49 ` [PATCH 06/10] exportfs: allow VFS flags in struct file_handle Thomas Bertschinger
2025-09-11 12:24 ` Amir Goldstein
2025-09-10 21:49 ` [PATCH 07/10] exportfs: new FILEID_CACHED flag for non-blocking fh lookup Thomas Bertschinger
2025-09-11 12:31 ` Amir Goldstein
2025-09-12 8:21 ` Dan Carpenter
2025-09-10 21:49 ` [PATCH 08/10] io_uring: add __io_open_prep() helper Thomas Bertschinger
2025-09-10 21:49 ` [PATCH 09/10] io_uring: add support for IORING_OP_OPEN_BY_HANDLE_AT Thomas Bertschinger
2025-09-10 21:49 ` [PATCH 10/10] xfs: add support for non-blocking fh_to_dentry() Thomas Bertschinger
2025-09-11 12:29 ` Christoph Hellwig
2025-09-11 12:39 ` Amir Goldstein
2025-09-11 15:15 ` Thomas Bertschinger
2025-09-11 15:16 ` Amir Goldstein
2025-09-11 12:38 ` Amir Goldstein
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=20250911005312.GU31600@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=io-uring@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=tahbertschinger@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