On Tue, 2010-01-26 at 16:12 -0500, Mike Snitzer wrote: > > > > > > > > > > Nice simplification Mike, as discussed on IRC. > > > > > > Ack. > > > > > > > Actually, the more I think about it I am not sure about sending the > > uevent in the case where dm_resume() fails. Seems like we should send > > it since the map could have changed - depends on whether we went through > > that 'if (new_map)' block. > > Pretty sure we resolved this. As we discussed (just after you sent this > last reply); for the benefit of others: > > <dave> so the change uevent here really means "resume was successful" > <mike> yes > <dave> wait - if we suspend it, but resume fails, shouldn't we still > send the event? > <mike> in that case the device will be left suspended; in terms of udev > that's not a "change" > <mike> device is wedged (suspended) > <mike> telling udev about it could just stack up other processes trying > to issue IO to it > <mike> but to be honest I don't know what the purist definition of what > a "change" uevent is; I'm just treating it as telling some blackbox that > DM device has changed and is functional > <dave> that does make sense > Yes, I should have stopped with my original Ack! -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
