From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9DD4C279 for ; Tue, 9 Aug 2016 08:08:10 +0000 (UTC) Received: from mail-io0-f196.google.com (mail-io0-f196.google.com [209.85.223.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F3BFCFF for ; Tue, 9 Aug 2016 08:08:09 +0000 (UTC) Received: by mail-io0-f196.google.com with SMTP id i199so323882ioi.1 for ; Tue, 09 Aug 2016 01:08:09 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20160804095049.GA30029@kroah.com> References: <20160727192040.GL5537@wotan.suse.de> <10281749.h0nm8HgLR9@vostro.rjw.lan> <4826466.kMrAaT2rsn@avalon> <87d1lpose8.fsf@intel.com> <20160804095049.GA30029@kroah.com> From: Daniel Vetter Date: Tue, 9 Aug 2016 10:08:07 +0200 Message-ID: To: Greg KH Content-Type: text/plain; charset=UTF-8 Cc: "ksummit-discuss@lists.linuxfoundation.org" , Mauro Carvalho Chehab , "rafael.j.wysocki" , "vegard.nossum@gmail.com" , Marek Szyprowski , Valentin Rothberg Subject: Re: [Ksummit-discuss] [TECH TOPIC] Addressing complex dependencies and semantics (v2) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, Aug 4, 2016 at 11:50 AM, Greg KH 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? > 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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch