Re: Why is the deferred initcall patch not mainline?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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:

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
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Index of Archives]     [Gstreamer Embedded]     [Linux MMC Devel]     [U-Boot V2]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux ARM Kernel]     [Linux OMAP]     [Linux SCSI]

  Powered by Linux