Hi Ueda-san, Kiyoshi Ueda wrote: > On 01/21/2010 07:58 AM +0900, Takahiro Yasui wrote: >> Kiyoshi Ueda wrote: >>> On 01/20/2010 05:40 AM +0900, Takahiro Yasui wrote: >>>> Introduce a target handler, cancel_presuspend, to cancel status changes >>>> done by a target specific presuspend handler. >>> How about using ->resume as a cancelling method? >>> Though you have to audit existing targets' ->resume handler, >>> I think it's better idea than adding another target handler >>> just for this purpose. > <snip> >> I'm afraid that we need to modify each target's resume handler so that >> they work properly even after processing presuspend handler but before >> postsuspend handler. >> >> Please let me know if there is some oversight. > > There is no oversight. > Perhaps I should have said 'audit (and modify if necessary)'. > > If auditing and modifying all targets are difficult, I don't object > your approach which adds ->cancel_presuspend. > But ->cancel_presuspend should be a subset of ->resume and it should > make some code duplication. If ->resume can always restore target state > correctly, it may avoid such duplication. > > Althrough I'm not sure the following idea is really reasonable, > I think it should be worth to consider about it: > When ->postsuspend is called and the device is really suspended, > DMF_SUSPENDED flag is set in md->flags. > So targets' ->resume handler can use it to check ->postsuspend > had been called or not. Hmm. It looks good idea. By exporting dm_suspended(), targets running in kernel space, can get the current status and choose actions to cancel state changes done in presuspend(). One execption is dm-log-userspace. It calls user space functions. So other solution is needed. I will try to update this patch set according to your suggestions. Thanks, Taka -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
