Re: [RFC][PATCHES] convert ->getgeo() from block_device of partition to gendisk

[Jens Axboe <axboe@kernel.dk>]

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@kernel.dk>
> 
> 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