[systemd-devel] udev interface naming for SR-IOV VFs
lennart at poettering.net
Sun May 3 08:34:16 PDT 2015
On Fri, 01.05.15 11:04, Dan Kenigsberg (danken at 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 (nirsof at 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 Poettering, Red Hat
More information about the systemd-devel