On Wed, Jun 04, 2025 at 09:53:10AM +0200, Christian Brauner wrote: > On Wed, Jun 04, 2025 at 12:13:38AM +0530, Anuj gupta wrote: > > > 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. 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.
