Re: [Ksummit-discuss] [TECH TOPIC] Addressing complex dependencies and semantics (v2)

[Jani Nikula <jani.nikula@intel.com>]

On Thu, 28 Jul 2016, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> Let's not demonize deferred probing, I think it's a good safety net to
> be used as a last resort when everything else failed. The problem is
> that we're using it as our primary mean to order initialization, and
> that leads to all sorts of inefficient behaviours at boot time.

One problem we have with deferred probing (and the reason we're not
using it to fix a bug we still have) is that it essentially requires you
to undo everything you've done before realizing you should return
-EPROBE_DEFER. In our case, we have maybe 90% of our initialization done
at that point, and this goes into the full module unload/reload
territory.

So I admit to being pretty clueless wrt the fine details of module
loading, but I'm wondering if there could be any way of the module being
loaded telling the kernel (via a call, not by returning from probe) to
hold its horses for a while, and keep loading other modules. Sort of
like deferred probe, but without the full cleanup-retry cycle. The call
would return to the module later (not unlike deferred probe retries the
probe), and you could try again whatever it was that made you realize
you need to defer.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center