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
