On Fri, May 11, 2018 at 01:30:01PM -0700, Omar Sandoval wrote: > On Fri, May 11, 2018 at 09:05:38PM +0100, Al Viro wrote: > > On Thu, May 10, 2018 at 11:30:10PM -0700, Omar Sandoval wrote: > > > do_blockdev_direct_IO(struct kiocb *iocb, struct inode *inode, > > > struct block_device *bdev, struct iov_iter *iter, > > > get_block_t get_block, dio_iodone_t end_io, > > > - dio_submit_t submit_io, int flags) > > > + dio_submit_t submit_io, int flags, void *private) > > > > Oh, dear... That's what, 9 arguments? I agree that the hack in question > > is obscene, but so is this ;-/ > > So looking at these one by one, obviously needed: > > - iocb > - inode > - iter > > bdev is almost always inode->i_sb->s_bdev, except for Btrfs :( > > These could _maybe_ go in struct kiocb: > > - flags could maybe be folded into ki_flags > - private could maybe go in iocb->private, but I haven't yet read > through to figure out if we're already using iocb->private for direct > I/O > > That leaves the callbacks, get_block, end_io, and submit_io. Perhaps we > can add those to inode_operations?
Or, perhaps, btrfs shouldn't be using the common helper? The question is not where to stash the bits and pieces - it's how unreadable the callers are and how much boilerplate/hidden information is involved... -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
