On Wed, Jun 04, 2025 at 12:57:18AM -0700, Christoph Hellwig wrote:

On Wed, Jun 04, 2025 at 09:53:10AM +0200, Christian Brauner wrote:

quoted

On Wed, Jun 04, 2025 at 12:13:38AM +0530, Anuj gupta wrote:

quoted

quoted

Hm, I wonder whether we should just make all of this an extension of the
new file_getattr() system call we're about to add instead of adding a
separate ioctl for this.

Hi Christian,
Thanks for the suggestion to explore file_getattr() for exposing PI
capabilities. I spent some time evaluating this path.

Block devices don’t implement inode_operations, including fileattr_get,
so invoking file_getattr() on something like /dev/nvme0n1 currently
returns -EOPNOTSUPP.  Supporting this would require introducing
inode_operations, and then wiring up fileattr_get in the block layer.

Given that, I think sticking with an ioctl may be the cleaner approach.
Do you see this differently?

Would it be so bad to add custom inode operations?
It's literally just something like:

That doesn't help as the inode operations for the underlying block device
inode won't ever be called.  The visible inode is the block device node
in the containing file system.

Ah, it's the same thing as with sockets, I forgot about that. Thanks.

Given fileattr get/set seems to be about the actual files in the file
system, using them for something that affects the I/O path for block
device nodes does not feel like a good fit.  And I think the reason they
are inode and not file operations is exactly to be able to cover
attributes always controlled by the containing file system.

Yes, that seems fine then.