On Thu, Jun 20, 2024 at 11:43:44AM -0400, Kent Overstreet wrote: > On Thu, Jun 20, 2024 at 05:30:50PM +0200, Christoph Hellwig wrote: > > On Thu, Jun 20, 2024 at 02:54:09PM +0100, Matthew Wilcox wrote: > > > I'm against it. Block devices only do sector-aligned IO and we should > > > not pretend otherwise. > > > > While I agree with that, the bvec_iter is actually used in a few other > > places and could be used in more, and the 512-byte sector unit bi_sector > > is the only weird thing that's not useful elsewhere. So turning that > > into a > > > > u64 bi_addr; > > > > that is byte based where the meaning is specific to the user would > > actually be kinda nice. For traditional block users we'd need a > > bio_sector() helpers similar to the existing bio_sectors() one, > > but a lot of non-trivial drivers actually need to translated to > > a variable LBA-based addressing, which would be (a tiny little bit) > > simpler with the byte address. As bi_size is already in bytes > > it would also fit in pretty naturally with that. > > > > The only thing that is really off putting is the amount of churn that > > this would cause. > > I'm being imprecise when I just say 'struct bio'; there's things in > there that are block layer specific but there are also things in there > you want that aren't block layer specific (completion callback, write > flags, s/bi_bdev/bi_inode and that as well, perhaps). It's not at all > clear to me we'd want to deal with the churn to split that up or make > bio itself less block layer specific (although, but when I say 'aiming > for commality with struct bio' that sort of thing is what I have in > mind. > > But more immediately, yes - bi_addr as all we need for this, and like > you said I think it'd be a worthwhile change. Still not clear why you need unaligned bi_addr for bio, if this bio needs to call submit_bio(), it has to be aligned. Otherwise, you could invent any structure for this purpose, and the structure can be payload of bio for avoiding extra allocation, even it can be FS generic structure. Thanks, Ming
