On Fri, 01.05.15 11:04, Dan Kenigsberg (dan...@redhat.com) wrote: > On Mon, Apr 20, 2015 at 08:43:21PM +0200, Lennart Poettering wrote: > > On Fri, 17.04.15 14:19, Nir Soffer (nir...@gmail.com) wrote: > > > > > - You may wait for unrelated events that happen to trigger in the same > > > time, waiting after the new interfaces are ready. > > > > > > I think you need something like: > > > > > > while True: > > > try: > > > udevadm.settle(1) > > > except udevadm.Timeout: > > > pass > > > else: > > > if all devices are ready: > > > break > > > time.sleep(1) > > > > Please never use udevadm settle in new code. > > Could you explain why? Is it because we are not sure if "our" events > have not been queued when "settle" is called, or something more dramatic > that should be documented in udevadm(1)?
Well, when people use "udev settle" they do so usually because they assume that after they called it "all" devices of the kind they are looking for have shown up, and that all is good then. But that's really not how devices work these days, they can come and go at any time, and at boot we have no idea at what time they will "all" have appeared, as many of the subsystems (inclduing USB or things like iSCSI for example) can take pretty much any time they want before the devices pop up after powering on. Now of course, if you care only about SR-IOV and you know you triggered your devices manually right before it, then yes, what was triggered will have been processed at time of udev settle returning, and you are hence safe -- but even then it's actually not really doing what you really want it to do: it will settle until *all* devices currently being probed have finished being probed, which might be substantally more than what you are looking for. In all cases the right way to implement device handling in clients is to actually subscribe to things and wait for precisely for the devices you need, and not any longer. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
