On Tue, Feb 26, 2019 at 12:07:37PM +0800, Qu Wenruo wrote: > > > On 2019/2/25 下午11:46, Josef Bacik wrote: > > On Mon, Feb 25, 2019 at 01:26:57PM +0100, David Sterba wrote: > >> On Mon, Feb 25, 2019 at 08:17:52PM +0800, Qu Wenruo wrote: > >>> > >>> > >>> On 2019/2/25 下午8:15, David Sterba wrote: > >>>> On Mon, Feb 25, 2019 at 01:50:43PM +0800, Qu Wenruo wrote: > >>>>> All users of extent_io_tree::private_data are expecting struct inode*. > >>>>> So just use struct inode* to replace extent_io_tree::private_data, and > >>>>> this should provide better type check. > >>>>> > >>>>> Signed-off-by: Qu Wenruo <[email protected]> > >>>>> struct extent_io_tree { > >>>>> struct rb_root state; > >>>>> - void *private_data; > >>>>> + struct inode *inode; > >>>>> u64 dirty_bytes; > >>>>> int track_uptodate; > >>>>> spinlock_t lock; > >>>> > >>>> So this is effectively reverting c6100a4b4e3d1650deafd ("Btrfs: replace > >>>> tree->mapping with tree->private_data"), > >>> > >>> That commit message doesn't explain why this is needed for btree_inode > >>> removal. > >>> > >>> Any idea what the extra type would be used in that case? > >> > >> I don't know, Josef in CC to answer that. > > > > Yeah there's a mapping tree thing I make to keep track of the metadata, it > > holds > > the radix tree for the eb's and a bunch of other stuff. This needs to stay > > a > > void *. Thanks, > > Then what about an union here? > > BTW, for no btree_inode case, how do we distinguish regular inode > pointer with yours? An extra member? >
We don't have to, the only place the inode is used is when doing the callbacks. The callbacks are implementation specific, so the btree extent_io callbacks know that the void *private_data is their struct btrfs_eb_info, and the inode ones know it's their struct inode *. Thanks, Josef
