[libvirt] [PATCH 1/3] nodedev: Move device enumumeration out of nodeStateInitialize

[Erik Skultety]

On Thu, Dec 14, 2017 at 08:25:34AM -0500, John Ferlan wrote:
>
>
> On 12/14/2017 05:42 AM, Erik Skultety wrote:
> > On Sat, Dec 09, 2017 at 12:29:12PM -0500, John Ferlan wrote:
> >> Let's move the udevEnumerateDevices into a thread to "speed
> >> up" the initialization process. If the enumeration fails we
> >> can set the Quit flag to ensure that udevEventHandleCallback
> >> will not run.
> >>
> >> Signed-off-by: John Ferlan <jferlan at redhat.com>
> >> ---
> >>  src/node_device/node_device_udev.c | 27 +++++++++++++++++++++++++--
> >>  1 file changed, 25 insertions(+), 2 deletions(-)
> >>
> >
> > Speedup's okay (even though I don't expect anything significant), but if
> > something goes wrong with udev, we start into a sort of crippled state where
> > you're still able to start machines, but only if these don't make use of NPIV
> > in a sense that a vHBA would need to be created, or managed direct-assigned PCI
> > devices. Prior to this change if enumeration failed, the daemon terminated - I
> > think this is an improvement.
> >
> > Reviewed-by: Erik Skultety <eskultet at redhat.com>
> >
>
> So as a "next step" - do you think it'd be worthwhile to actually
> implement the nodeStateReload functionality?  I think we have enough

I wasn't going to suggest that, since there are many other thing on the plate
that need attention, but since you mentioned it, yes, I think it would be
worthwhile to have that kind of functionality. On the other hand, since there's
the resonating incentive on reworking our architecture, we also need to think
with respect to that whether such a change is still going to make sense even
after we make any architectural changes or many things are going to """solve"""
by the nature of it. With that said and not giving not much thought to it, I
don't think StateReload feature would be one of such things.

Erik