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: > > 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. 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.
