Re: [PATCH] block: emit disk ro uevent in device_add_disk()

[Uday Shankar <ushankar@purestorage.com>]

On Mon, Mar 07, 2022 at 07:39:39AM +0100, Hannes Reinecke wrote:
> Why not add the 'DISK_RO=1' setting directly to the 'add' event?
> That would be the logical thing to do, no?
I agree, and initially had a patch that did just this. However, for SCSI
disks the DISK_RO property is only ever announced via change uevents,
and applications such as dm-multipath may not pick up on DISK_RO if it
shows up in an add uevent instead. This patch maintains compatibility
with SCSI in that sense. 

Christoph Hellwig wrote:
> I don't see any such pattern there.
Note how sd_revalidate_disk (which does readonly setting) is called both
before and after device_add_disk. Note also how set_disk_ro is called
twice in sd_read_write_protect_flag, to ensure that the ro state flips
(at least in the case where the ro state should be 1). The only
reasoning I can think of for this pattern is the one I mentioned.

> I also don't see what the point is.  KOBJ_CHANGE uevents tell about a
> change in device state.  But if a device is marked read-only before
> disk_add that read-only state is already visible by the time the
> device is added and thus shows up in sysfs, and we do not need an
> extra notification.
You are suggesting that I should patch the applications I care about to
pick up the ro state from sysfs instead of waiting for a change uevent,
correct?

Thanks,
Uday