From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
Anuj Gupta/Anuj Gupta <anuj20.g@samsung.com>,
jack@suse.cz, anuj1072538@gmail.com, axboe@kernel.dk,
viro@zeniv.linux.org.uk, brauner@kernel.org,
linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
joshi.k@samsung.com
Subject: Re: [RFC] fs: add ioctl to query protection info capabilities
Date: Tue, 03 Jun 2025 21:48:56 -0400 [thread overview]
Message-ID: <yq1jz5se0wc.fsf@ca-mkp.ca.oracle.com> (raw)
In-Reply-To: <aD6WjAVeSL0tNv7D@infradead.org> (Christoph Hellwig's message of "Mon, 2 Jun 2025 23:30:36 -0700")
Christoph,
>> It would require quite a bit of rototilling to metadata-ize the block
>> layer plumbing at this point. But for a new user API, I do think we
>> should try to align with the architecture outlined in the standards.
>
> As in exporting the total metadata size and PI tuple size?
Yep. An alternative would be to have uapi defines for the PI tuple size
given each of the checksum types. But I do think it is clearer to make
the sizes explicit in the returned struct.
--
Martin K. Petersen
prev parent reply other threads:[~2025-06-04 1:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20250527105950epcas5p1b53753ab614bf6bde4ffbf5165c7d263@epcas5p1.samsung.com>
2025-05-27 10:42 ` [RFC] fs: add ioctl to query protection info capabilities Anuj Gupta
2025-05-29 3:02 ` Martin K. Petersen
2025-05-29 7:12 ` Anuj Gupta/Anuj Gupta
2025-05-29 17:59 ` Eric Biggers
2025-05-30 5:24 ` Christian Brauner
2025-06-03 18:43 ` Anuj gupta
2025-06-04 7:53 ` Christian Brauner
2025-06-04 7:57 ` Christoph Hellwig
2025-06-05 8:24 ` Christian Brauner
2025-05-29 21:14 ` [RFC] " Andreas Dilger
2025-06-03 3:12 ` [RFC] fs: " Martin K. Petersen
2025-06-03 6:30 ` Christoph Hellwig
2025-06-04 1:48 ` Martin K. Petersen [this message]
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=yq1jz5se0wc.fsf@ca-mkp.ca.oracle.com \
--to=martin.petersen@oracle.com \
--cc=anuj1072538@gmail.com \
--cc=anuj20.g@samsung.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=hch@infradead.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.