[dm-devel] [PATCH 1/3] dm: a basic support for using the select or poll function

Alasdair G Kergon agk at redhat.com
Thu May 11 20:21:04 UTC 2017


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




More information about the dm-devel mailing list