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