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.
