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. > This code is really intended for a very specialized kernel configuration, > where all > the modules are statically linked, and indeed module loading itself is turned > off. > I think that's a minority of Linux deployments out there. This configuration > implies some other attributes, like configuration for very small size and/or > very > fast boot, where KALLSYMS may not be present, and other kernel features may > not be available as well. Indeed, in the smallest systems /proc or /sys may > not > be there, so an alternative (maybe a sysctl or even a new syscall) might be > appropriate. > > Quite frankly, the hacky way this is often done is to make stuff like this a > one-time side effect of a rarely called syscall (like sync). Please note I'm > not > recommending this for mainline, just pointing out there are interesting ways > that embedded developers just make the existing code work for their weird > cases. Agreed. However if you're looking for a solution that may go into mainline, it just can't be hackish like that. There might be generic solutions that meet your goal while still being useful to others. Focussing on the best way to implement a particular solution while there might be other solutions to explore is a bad approach. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
