On 9/3/25 8:09 AM, Al Viro wrote: > On Fri, Jul 18, 2025 at 03:20:02PM -0600, Jens Axboe wrote: >> On 7/18/25 1:26 PM, Al Viro wrote: >>> Instances of ->getgeo() get a block_device of partition and >>> fill the (mostly fake) geometry information of the disk into caller's >>> struct hd_geometry. It *does* contain one member related to specific >>> partition (the starting sector), but... that member is actually filled >>> by the callers of ->getgeo() (blkdev_getgeo() and compat_hdio_getgeo()), >>> leaving the instances partition-agnostic. >>> >>> All actual work is done using bdev->bd_disk, be it the disk >>> capacity, IO, or cached geometry information. AFAICS, it would make >>> more sense to pass it gendisk to start with. >>> >>> The series is pretty straightforward - conversion of scsi_bios_ptable() >>> and scsi_partsize() to gendisk, then the same for ->bios_param(), then >>> ->getgeo() itself. It sits in viro/vfs.git#rebase.getgeo, individual patches >>> in followups. >>> >>> Comments, objections? >> >> None from me, looks fine: >> >> Acked-by: Jens Axboe <axboe@xxxxxxxxx> > > Which tree would you prefer it to go through? Currently it's in viro/vfs.git > #work.getgeo (rebased to 6.17-rc1, no changes since the last posting); > I can merge it into vfs/viro #for-next and push it to Linus in the next > window, unless you prefer it to go through the block tree... Assuming it merges cleanly with my for-6.18/block tree, which I believe it should as there's not that much in there, I'm fine with it going in via your vfs tree. Which is also why I provided my acked-by. It probably _should_ go in via the block tree, but little risk of complications here, so... -- Jens Axboe
