Re: [PATCH v2 0/29] block: Make blkdev_get_by_*() return handle
Christoph Hellwig <[email protected]>
| Newsgroups | org.kernel.vger.reiserfs-devel,dev.linux.lists.dm-devel,dev.linux.lists.drbd-dev,net.sourceforge.lists.linux-f2fs-devel,org.infradead.lists.linux-mtd,org.infradead.lists.linux-nvme,org.kernel.vger.linux-bcache,org.kernel.vger.linux-block,org.kernel.vger.linux-btrfs,org.kernel.vger.linux-ext4,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-nfs,org.kernel.vger.linux-nilfs,org.kernel.vger.linux-pm,org.kernel.vger.linux-raid,org.kernel.vger.linux-s390,org.kernel.vger.linux-scsi,org.kernel.vger.linux-xfs,org.kernel.vger.target-devel,org.kvack.linux-mm,org.ozlabs.lists.linux-erofs,org.xenproject.lists.xen-devel |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Aug 25, 2023 at 03:47:56PM +0200, Jan Kara wrote: > I can see the appeal of not having to introduce the new bdev_handle type > and just using struct file which unifies in-kernel and userspace block > device opens. But I can see downsides too - the last fput() happening from > task work makes me a bit nervous whether it will not break something > somewhere with exclusive bdev opens. Getting from struct file to bdev is > somewhat harder but I guess a helper like F_BDEV() would solve that just > fine. > > So besides my last fput() worry about I think this could work and would be > probably a bit nicer than what I have. But before going and redoing the whole > series let me gather some more feedback so that we don't go back and forth. > Christoph, Christian, Jens, any opinion? I did think about the file a bit. The fact that we'd need something like an anon_file for the by_dev open was always a huge turn off for me, but maybe my concern is overblown. Having a struct file would actually be really useful for a bunch of users.