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

Greg KH greg at kroah.com
Tue Aug 9 08:17:34 UTC 2016


On Tue, Aug 09, 2016 at 10:08:07AM +0200, Daniel Vetter wrote:
> On Thu, Aug 4, 2016 at 11:50 AM, Greg KH <greg at kroah.com> wrote:
> > On Thu, Aug 04, 2016 at 11:22:23AM +0300, Jani Nikula wrote:
> >> 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.
> >
> > Nope, it doesn't work that way, sorry.
> 
> Why? If I just postpone the entire driver load to an async worker and
> then block if it's not there, that should work?

Maybe, but the code patch from probe() in the driver core, and module
loader, might be assuming that all is ok, only to have your async init
later on realize that things are not ok.  How you could propagate that
error back into the driver core might be difficult, if not impossible.

> > Nice try, just unwind your initialization properly :)
> 
> There's a slight pratical problem of this being hard to test. Sure in
> theory it's easy, but given how often we bomb normal module unload
> already (and that's something our CI tests) practice disagrees.

probe()/disconnect()/probe() in the driver core as an option might be a
fun way to stress this as others have pointed out here.

thanks,

greg k-h


More information about the Ksummit-discuss mailing list