On Thu, May 11, 2017 at 09:49:14PM +0200, Martin Wilck wrote: > Here is an idea: the best way to avoid the race mentioned by Mike might > be to set priv->global_event_nr to the highest event nr reported by the > DM_LIST_DEVICES ioctl when this ioctl returns. DM_LIST_DEVICES would > then represent your "separate action", which would fit quite well, and > the DM_DEV_ARM_POLL ioctl wouldn't be needed. It would be guaranteed > that if any event had occured after the previous DM_LIST_DEVICES, > whether or not that had been before or after the poll() call, userspace > would notice. It's not really good practice to overload operations by adding and relying upon side-effects. Yes, you could add a flag to control the side-effect, but a separate ioctl seems to be a perfectly reasonable approach in the present case, allowing for flexible use and not forcing you to generate the list when you don't need it. We've already got examples of both other approaches - DM_DEV_WAIT_CMD taking the last known event_nr as input, and @stats_print_clear reporting and resetting counters in the same operation. Alasdair -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
