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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.