All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <djwong@kernel.org>
To: Kanchan Joshi <joshi.k@samsung.com>
Cc: brauner@kernel.org, hch@lst.de, jack@suse.cz, cem@kernel.org,
	kbusch@kernel.org, axboe@kernel.dk, linux-xfs@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, gost.dev@samsung.com,
	linux-api@vger.kernel.org
Subject: Re: [PATCH v2 1/5] fs: add generic write-stream management ioctl
Date: Tue, 10 Mar 2026 13:44:18 -0700	[thread overview]
Message-ID: <20260310204418.GY1105363@frogsfrogsfrogs> (raw)
In-Reply-To: <2cde8902-6d50-4035-b9c4-89bd5e2c9468@samsung.com>

On Tue, Mar 10, 2026 at 11:25:25PM +0530, Kanchan Joshi wrote:
> On 3/9/2026 10:03 PM, Darrick J. Wong wrote:
> >> +struct fs_write_stream {
> >> +	__u32		op_flags;	/* IN: operation flags */
> >> +	__u32		stream_id;	/* IN/OUT:  stream value to assign/guery */
> >> +	__u32		max_streams;	/* OUT: max streams values supported */
> >> +	__u32		rsvd;
> >> +};
> > This isn't an very cohesive interface -- GET_MAX probably only needs
> > op_flags and max_streams, right?  And GET/SET only use op_flags and
> > stream_id, right?
> 
> Yeah, right. That's the trade-off with swiss army knife type ioctl which 
> uses op_flags to decide what it should do. Apart from keeping a single 
> ioctl I was thinking a bit about extensibility (for anything new we may 
> be able to do a new op_flags with some rsvd or union) too. But if you 
> feel strong about this, I can take 3 ioctl route?

struct fs_write_stream {
	__u32		op_flags;
	union {
		__u32	stream_id;
		__u32	max_ids;
	};
	__u64		reserved;
};

perhaps?  You might want to look into whether or not we're allowed to
have anonymous unions in UAPI headers.  We all ❤️ C11, right?

--D

> >> +#define FS_WRITE_STREAM_OP_GET_MAX		(1 << 0)
> >> +#define FS_WRITE_STREAM_OP_GET			(1 << 1)
> >> +#define FS_WRITE_STREAM_OP_SET			(1 << 2)
> >> +
> >> +#define FS_IOC_WRITE_STREAM		_IOWR('f', 43, struct fs_write_stream)
> > EXT4_IOC_CHECKPOINT already took 'f' / 43.  I/think/ there's no problem
> > because its argument is a u32 and ioctl definitions incorporate the
> > lower bits of of the argument size but you might want to be careful
> > anyway.
> 
> Indeed, thanks!
> 

  reply	other threads:[~2026-03-10 20:44 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20260309053425epcas5p32886580a4fbe646ceee66f2864970e9f@epcas5p3.samsung.com>
2026-03-09  5:29 ` [PATCH v2 0/5] write streams and xfs spatial isolation Kanchan Joshi
2026-03-09  5:29   ` [PATCH v2 1/5] fs: add generic write-stream management ioctl Kanchan Joshi
2026-03-09 16:33     ` Darrick J. Wong
2026-03-10 17:55       ` Kanchan Joshi
2026-03-10 20:44         ` Darrick J. Wong [this message]
2026-03-09  5:29   ` [PATCH v2 2/5] iomap: introduce and propagate write_stream Kanchan Joshi
2026-03-09 16:34     ` Darrick J. Wong
2026-03-10 17:58       ` Kanchan Joshi
2026-03-09  5:29   ` [PATCH v2 3/5] xfs: implement write-stream management support Kanchan Joshi
2026-03-09 16:38     ` Darrick J. Wong
2026-03-10 18:07       ` Kanchan Joshi
2026-03-09  5:29   ` [PATCH v2 4/5] xfs: steer allocation using write stream Kanchan Joshi
2026-03-09 12:45     ` kernel test robot
2026-03-09 20:01     ` kernel test robot
2026-03-10  5:47     ` Dave Chinner
2026-03-10 19:03       ` Kanchan Joshi
2026-03-10 22:44         ` Dave Chinner
2026-03-11  9:59           ` Kanchan Joshi
2026-03-09  5:29   ` [PATCH v2 5/5] xfs: introduce software write streams Kanchan Joshi
2026-03-10  6:01     ` Dave Chinner
2026-03-09 15:40   ` [PATCH v2 0/5] write streams and xfs spatial isolation Christoph Hellwig
2026-03-10 21:19     ` Kanchan Joshi

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=20260310204418.GY1105363@frogsfrogsfrogs \
    --to=djwong@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=cem@kernel.org \
    --cc=gost.dev@samsung.com \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=joshi.k@samsung.com \
    --cc=kbusch@kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    /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.