Re: Recommendation for activating a deferred module init in the kernel

[David VomLehn <dvomlehn@cisco.com>]

Tim Bird wrote:
> Hi all,
> 
> I am working with a product team on bootup time issues.  One technique that we
> are forward-porting from an old kernel (and that I thought I might work on
> mainlining) is to compile modules statically into the kernel, but defer their
> initialization until after boot time.
...
> One of the main sub-systems that we defer initialization of this way is USB,
> and this saves quite a bit of time.  (Of course the same, or slightly more CPU
> cycles are eventually used during bootup time.  But this lets us get to user
> space quicker so we can start user-visible applications faster.)
> 
> I'm not that happy using an ioctl for this trigger.  What is the preferred
> method of activating a kernel feature like this? I presume something in /proc
> or /sys, but I'm not sure.

 From your description, it seems as though you always want to do the
initialization, you just may want to delay it until well after starting up user
space. If something like this were performance-critical, an ioctl might be 
justified, but this would be a one-time trigger. I think that making this as 
closely analogous to loading a kernel module as possible is a good conceptual 
approach. Since you might choose, at run time, whether or not to load a kernel 
module, it makes sense to do this on a device-by-device basis. To me, that 
suggests doing something in /sys.

My first impression was that this was an awful kludge, but drawing the parallel 
to loadable modules makes me not only happier, but also leads me into wondering 
if there shouldn't be a generic framework for supporting this. So, instead of 
using module_init, there might be some other macro that indicated that this 
driver was to be initialized in a deferred, and optional, fashion.

-- 
David VomLehn, dvomlehn@cisco.com
The opinions expressed herein are likely mine, but might not be my employer's...




     - - - - -                              Cisco                            - - - - -         
This e-mail and any attachments may contain information which is confidential, 
proprietary, privileged or otherwise protected by law. The information is solely 
intended for the named addressee (or a person responsible for delivering it to 
the addressee). If you are not the intended recipient of this message, you are 
not authorized to read, print, retain, copy or disseminate this message or any 
part of it. If you have received this e-mail in error, please notify the sender 
immediately by return e-mail and delete it from your computer.