From: Christoph Hellwig <hch@lst.de>
To: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
Anuj Gupta <anuj20.g@samsung.com>,
Kanchan Joshi <joshi.k@samsung.com>,
linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
io-uring@vger.kernel.org
Subject: Re: [PATCH 1/2] fs: add a FMODE_ flag to indicate IOCB_HAS_METADATA availability
Date: Mon, 25 Aug 2025 15:35:16 +0200 [thread overview]
Message-ID: <20250825133516.GA14412@lst.de> (raw)
In-Reply-To: <20250825-randbemerkung-machbar-ae3dde406069@brauner>
On Mon, Aug 25, 2025 at 02:01:07PM +0200, Christian Brauner wrote:
> On Thu, Aug 21, 2025 at 10:42:13AM +0200, Christoph Hellwig wrote:
> > On Wed, Aug 20, 2025 at 11:40:36AM +0200, Christian Brauner wrote:
> > > I meant something like this which should effectively be the same thing
> > > just that we move the burden of having to use two bits completely into
> > > file->f_iocb_flags instead of wasting a file->f_mode bit:
> >
> > Yeah, that could work. But I think the double use of f_iocb_flags is
> > a bit confusing. Another option at least for this case would be to
> > have a FOP_ flag, and then check inside the operation if it is supported
> > for this particular instance.
>
> Do you want to try something like that? Maybe we can do this for other
> FMODE_*-based IOCB_* opt{in,outs}?
Yes, I also need to move on of the FOP_ flags to a scheme like that.
However I'm pretty busy at the momen, so I'm unlikely to get to it
before mid-September.
next prev parent reply other threads:[~2025-08-25 13:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-19 8:24 io_uring / dio metadata fixes Christoph Hellwig
2025-08-19 8:25 ` [PATCH 1/2] fs: add a FMODE_ flag to indicate IOCB_HAS_METADATA availability Christoph Hellwig
2025-08-19 9:14 ` Christian Brauner
2025-08-19 9:22 ` Christoph Hellwig
2025-08-19 10:14 ` Christian Brauner
2025-08-19 13:34 ` Christoph Hellwig
2025-08-20 9:40 ` Christian Brauner
2025-08-21 8:42 ` Christoph Hellwig
2025-08-25 12:01 ` Christian Brauner
2025-08-25 13:35 ` Christoph Hellwig [this message]
2025-08-19 8:25 ` [PATCH 2/2] block: don't silently ignore metadata for sync read/write Christoph Hellwig
2025-08-20 3:23 ` Martin K. Petersen
2025-08-20 9:13 ` io_uring / dio metadata fixes Christian Brauner
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=20250825133516.GA14412@lst.de \
--to=hch@lst.de \
--cc=anuj20.g@samsung.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=io-uring@vger.kernel.org \
--cc=jack@suse.cz \
--cc=joshi.k@samsung.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.