Re: [PATCH vfs.all 22/26] block: stash a bdev_file to read/write raw blcok_device

[Yu Kuai <yukuai1@huaweicloud.com>]

Hi,

在 2024/04/07 9:51, Al Viro 写道:
> On Sun, Apr 07, 2024 at 09:18:20AM +0800, Yu Kuai wrote:
> 
>> Yes, patch 23-26 already do the work to remove the field block_device
>> and convert to use bdev_file for iomap and buffer_head.
> 
> What for?  I mean, what makes that dummy struct file * any better than
> struct block_device *?  What's the point?
> 
> I agree that keeping an opened struct file for a block device is
> a good idea - certainly better than weird crap used to carry the
> "how had it been opened" along with bdev.  But that does *not*
> mean not keeping ->s_bdev around; we might or might not find that
> convenient, but it's not "struct block_device is Evil(tm), let's
> exorcise".
> 
> Why do we care to do anything to struct buffer_head?  Or to
> struct bio, for that matter...

Other than raw block_device fops, other filesystems can use the opened
bdev_file directly for iomap and buffer_head, and they actually don't
need to reference block_device anymore. The point here is that whether
we want to keep a special handling for block_device fops or not. There
are two proposes now:

- one is from Christian to keep using block_device for block_device
fops, in order to do that, a new flag and some special handling is added
to iomap and buffer_head. See the patch from last version [1].

- one is from this patchset, allocate a *dummy* bdev_file just for iomap
and buffer_head to access bdev and bd_inode.

I personally prefer the later one, that's why there is a new version,
however, what do I know? That will depend on how people think.

[1] 
https://lore.kernel.org/all/20240222124555.2049140-20-yukuai1@huaweicloud.com/
Thanks,
Kuai

> 
> I'm not saying that parts of the patchset do not make sense on
> their own, but I don't understand what the last part is all
> about.
> 
> Al, still going through that series...
> .
>