Re: Why is the deferred initcall patch not mainline?

[Alexandre Belloni <alexandre.belloni@free-electrons.com>]

On 23/10/2014 at 13:56:44 -0400, Nicolas Pitre wrote :
> On Thu, 23 Oct 2014, Bird, Tim wrote:
> 
> > I'm not sure why this attention to reading the status.  The salient feature
> > here is that the initializations are deferred until user space tells the kernel
> > to proceed.  It's the initiation of the trigger from user-space that matters.
> > The whole purpose of this feature is to defer some driver initializations until
> > the product can get into a state where it is already ready to perform it's primary
> > function.  Only user space knows when that is.
> 
> This is still a rather restrictive view of the problem IMHO.
> 
> Let's step back a bit. Your concern is that some initcalls are taking 
> too long and preventing user space from executing early, right?  I'm 
> suggesting that they no longer prevent user space from executing 
> earlier.  Why would you then still want an explicit trigger from user 
> space?
> 
> > There seems to be a desire to have an automatic mechanism for triggering
> > the deferred initializations.  I'm OK with this, as long as there's some reasonable
> > use case for it.  There are lots of possible trigger mechanisms, including just
> > a simple timer, but I think it's important that the primary use case of 
> > 'trigger-when-user-space-says-to' is still supported.
> 
> Why a trigger?  I'm suggesting no trigger at all is needed.
> 
> Let all initcalls start initializing whenever they can.  Simply that 
> they shouldn't prevent user space from running early.
> 
> Because initcalls are running in parallel, then they must be using 
> separate kernel threads.  It may be possible to adjust their priority so 
> if one of them is actually using a lot of CPU cycles then it will run 
> only when all the other threads (including user space) are no longer 
> running.
> 

You probably can't do that without introducing race conditions. A number
of userspace libraries and script are actually expecting init and probe
to be synchronous. I will refer to the async probe discussion and the
following thread:

http://thread.gmane.org/gmane.linux.kernel/1781529

Anyway, your userspace will have to have a way to know what has been
initialized. On my side, I was also using that mechanism to delay the
network stack init but I still want to know when my dhcp client can
start for example.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com