On Wed, May 17, 2023 at 04:26:09PM +0200, Christoph Hellwig wrote: > On Wed, May 17, 2023 at 03:14:40PM +0200, Christian Brauner wrote: > > > Why would we want to pin it? That just means the device is open and > > > you're have a non-O_PATH mount. > > > > I think we're talking past each other. Both an O_PATH fd and a regular > > fd would work. But its often desirable to pass a regular fd. If > > userspace uses an O_PATH fd then the block device could be looked up > > later during mounting via blkdev_open(). > > > > But when you use a regular fd blkdev_open() will be called and the > > device resolved right at open time and we'll hold a reference to it. > > > > So that way userspace can immediately know whether the device can be > > opened/found. That's usually preferable. That's all I meant to say. > > I know what you mean. But based on the concept of how O_PATH and > block devices work it really doesn't make any sense to have a block > device handle for an O_PATH fd, except for the actual fd itself. Fwiw, I didn't mean to have a special device handler for an O_PATH fd. I really just tried to figure out whether it would make sense to have an fd-based block device lookup function because right now we only have blkdev_get_by_path() and we'd be passing blkdev fds through the mount api. But I understand now how I'd likely do it. So now just finding time to actually implement it.
