[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZOytnQV0CH+vEIrr@infradead.org>
Date: Mon, 28 Aug 2023 07:22:21 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Jan Kara <jack@...e.cz>
Cc: Al Viro <viro@...iv.linux.org.uk>, linux-fsdevel@...r.kernel.org,
linux-block@...r.kernel.org, Christoph Hellwig <hch@...radead.org>,
Alasdair Kergon <agk@...hat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Anna Schumaker <anna@...nel.org>, Chao Yu <chao@...nel.org>,
Christian Borntraeger <borntraeger@...ux.ibm.com>,
"Darrick J. Wong" <djwong@...nel.org>,
Dave Kleikamp <shaggy@...nel.org>,
David Sterba <dsterba@...e.com>, dm-devel@...hat.com,
drbd-dev@...ts.linbit.com, Gao Xiang <xiang@...nel.org>,
Jack Wang <jinpu.wang@...os.com>,
Jaegeuk Kim <jaegeuk@...nel.org>,
jfs-discussion@...ts.sourceforge.net,
Joern Engel <joern@...ybastard.org>,
Joseph Qi <joseph.qi@...ux.alibaba.com>,
Kent Overstreet <kent.overstreet@...il.com>,
linux-bcache@...r.kernel.org, linux-btrfs@...r.kernel.org,
linux-erofs@...ts.ozlabs.org, linux-ext4@...r.kernel.org,
linux-f2fs-devel@...ts.sourceforge.net, linux-mm@...ck.org,
linux-mtd@...ts.infradead.org, linux-nfs@...r.kernel.org,
linux-nilfs@...r.kernel.org, linux-nvme@...ts.infradead.org,
linux-pm@...r.kernel.org, linux-raid@...r.kernel.org,
linux-s390@...r.kernel.org, linux-scsi@...r.kernel.org,
linux-xfs@...r.kernel.org,
"Md. Haris Iqbal" <haris.iqbal@...os.com>,
Mike Snitzer <snitzer@...nel.org>,
Minchan Kim <minchan@...nel.org>, ocfs2-devel@....oracle.com,
reiserfs-devel@...r.kernel.org,
Sergey Senozhatsky <senozhatsky@...omium.org>,
Song Liu <song@...nel.org>,
Sven Schnelle <svens@...ux.ibm.com>,
target-devel@...r.kernel.org, Ted Tso <tytso@....edu>,
Trond Myklebust <trond.myklebust@...merspace.com>,
xen-devel@...ts.xenproject.org, Jens Axboe <axboe@...nel.dk>,
Christian Brauner <brauner@...nel.org>
Subject: Re: [PATCH v2 0/29] block: Make blkdev_get_by_*() return handle
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.
Powered by blists - more mailing lists