Hi,
在 2024/04/07 4:29, Al Viro 写道:
On Sat, Apr 06, 2024 at 08:42:06PM +0100, Al Viro wrote:
On Sat, Apr 06, 2024 at 05:09:26PM +0800, Yu Kuai wrote:
From: Yu Kuai <yukuai3@xxxxxxxxxx>
So that iomap and bffer_head can convert to use bdev_file in following
patches.
Let me see if I got it straight. You introduce dummy struct file instances
(no methods, nothing). The *ONLY* purpose they serve is to correspond to
opened instances of struct bdev. No other use is possible.
Yes, this is the only purpose.
You shove them into ->i_private of bdevfs inodes. Lifetime rules are...
odd.
In bdev_open() you arrange for such beast to be present. You never
return it anywhere, they only get accessed via ->i_private, exposing
it at least to fs/buffer.c. Reference to those suckers get stored
(without grabbing refcount) into buffer_head instances.
And all of that is for... what, exactly?
Put another way, what's the endgame here? Are you going to try and
propagate those beasts down into bio_alloc()? Because if you do not,
you need to keep struct block_device * around anyway.
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.
Or maybe you prefer the idea from last version to keep the block_device
field in iomap/buffer_head, and use it for raw block_device fops?
Thanks,
Kuai
We use ->b_bdev for several things:
* passing to bio_alloc() (quite a few places)
* %pg in debugging printks
* (rare) passing to write_boundary_block().
* (twice) passing to clean_bdev_aliases().
* (once) passing to __find_get_block().
* one irregular use as a key in lookup_bh_lru()
IDGI...
.
