On Fri, 2016-11-18 at 16:26 -0600, Benjamin Marzinski wrote: > The issue is that we simply need to work on processing the whole list > at > a time. Martin's filtering definitely has a place here. He is > correct > that if we get a delete uevent for a device, we don't need to process > any of the earlier ones. We do need to look at both the add and > change > uevents individually. For instance, one of the change uevents out of > a > group could be for changing the read-only status of a device. If we > just > took the most recent, we would miss that information. The good news > is > that we don't need to actually call uev_add_path and uev_update_path > once for each of these events. All we need to do is read through the > uev environment variables for all of them to find the information we > need (like change in ro status), and then call the function once with > that information. Do we need to implement the environment-merging ourselves? AFAICS this logic is implemented in udev itself. So if the last event for a given device is a change event, we'd just need to fetch the device properties from the udev db. Therefore IMO we just have to look at the last received event for a given path: - DELETE => discard the device - ADD => use the udev properties coming with the event - CHANGE => query udev db for current set of properties > At any rate, I'd rather get rid of the gazillion waiter threads > first. Hm, I thought the threads are good because this avoids one unresponsive device to stall everything? Martin -- Dr. Martin Wilck <mwilck@xxxxxxxx>, Tel. +49 (0)911 74053 2107 SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
