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